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ABSTRACT 


Upper-level  managers  at  Silas  B.  Hays  Army  Community  Hospital  (SBHACH),  Fort 
Ord,  CA,  are  tasked  with  the  administrative  operation  of  a  Medical  Treatment  Facility  pro¬ 
viding  various  health-care  services  to  the  surrounding  military  community.  This  broad 
mission  requires  hospital  administrators  to  analyze  large  amounts  of  data  when  commonly 
tasked  with  solving  ill-structured  problems  resulting  from  managing  such  a  large  hospital. 
The  thesis  research  presents  the  use  of  a  Decision  Support  System  (DSS)  to  support  upper- 
level  managers  faced  with  ill-structured  problems  and  discusses  the  use  of  structured  inter¬ 
views  in  deriving  the  resource  manager’s  critical  information  needs.  These  Critical  Success 
Factors  (CSFs)  are  presented  in  detail  and  proposed  measures  that  a  DSS  should  possess  to 
satisfy  these  critical  information  needs  are  identified.  The  design  of  the  first  iteration  of  the 
Resource  Management  DSS  using  structured  software  design  tools  provides  the  necessary 
documentation  from  which  the  system  may  be  implemented 
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I.  INTRODUCTION 


A.  BACKGROUND 

1.  General  Mission  of  U.  S.  Army  Health-Care  Services 

Like  any  precious  resource  in  the  Department  of  Defense  (DOD),  medical 
health-care  services  are  regarded  as  finite  and  subject  to  budgetary  limitations.  Within  the 
U.  S.  Army,  commanding  officers  of  Medical  Treatment  Facilities  (MTFs)  are  assigned  the 
responsibility  for  administration  of  patients  under  their  jurisdiction.  The  MTF  commanding 
officer  is  specifically  tasked  with  providing  the  best  possible  health  care  for  each  patient, 
ensuring  such  care  is  consistent  with  professional  health-care  procedures  and  standards 
[Army  Reg  40-3  85]. 

This  broad  mission,  coupled  with  fluctuating  expertise  levels  of  health-care 
providers  and  scarce  resources,  compounds  an  already  difficult  task  of  managing  a  MTF. 
The  Silas  B.  Hays  Army  Community  Hospital  (SBHACH),  Fort  Ord,  California,  is  no 
exception.  The  commanding  officer  and  his  staff  are  tasked  with  managing  the  daily  oper¬ 
ation  of  the  MTF  by  providing  professional  medical  health-care  services  to  different  levels 
of  DOD  personnel,  all  without  exceeding  annual  budget  funding.  Compliance  with  this 
goal  is  difficult,  requiring  the  analysis  of  large  amounts  of  information. 

2.  Need  for  Information  Management 

Resource  managers  at  SBHACH  draw  data  from  several  in-place  Management 
Information  Systems  (MIS)  to  support  decision  making.  Unfortunately  in  most  cases, 
extracted  data  from  an  existing  MIS  is  not  readily  useable.  Often  the  data  must  be  com¬ 
bined  with  other  MIS  outputs  and  put  into  a  recognizable  format  for  management  use.  For 
example,  to  find  the  average  cost  the  hospital  incurs  per  outpatient  visit  over  a  period  of 
time  requires  data  from  one  MIS  providing  total  outpatients  treated,  and  data  from  a  second 


MIS  providing  total  cost  spent  on  outpatients.  This  data  is  then  combined  into  a  useful 
ratio  for  SBHACH  resource  managers.  However,  extracting  and  correlating  data  into  use¬ 
ful  information  often  administratively  overburdens  managers.  Personnel  tasked  with 
extraction  and  correlation  tasks  sometimes  duplicate  effort,  repeat  the  same  procedures 
done  for  earlier  periods,  and  may  provide  varying  results  even  though  they  use  the  same 
data.  There  is  a  need  for  a  system  that  provides  a  systematic,  structured  approach  to  satisfy 
management  information  needs. 

A  Decision  Support  System  (DSS)  specifically  developed  for  SBHACH  resource 
managers  will  provide  this  structured  approach  by  supplying  on  request  timely  and  consis¬ 
tent  information,  which  is  extracted  and  correlated  without  undue  administrative  burden. 

B .  INTRODUCTION  TO  DECISION  SUPPORT  SYSTEMS  (DSS) 

A  DSS  is  a  computer-based,  interactive  system  that  aids  decision  makers  in  con¬ 
fronting  ill-structured  problems  through  the  use  of  data  and  analysis  [Sprague  82].  The 
role  of  a  DSS  is  to  provide  necessary  information  in  a  useable  format,  on  time,  to  the  deci¬ 
sion  maker  who  needs  it.  In  this  context,  a  properly  designed  DSS  for  SBHACH  will 
support  decision  makers  by  satisfying  information  needs.  The  DSS  on  demand  will  tie  into 
existing  MIS,  extract  necessary  data,  combine  this  data  with  other  outputs  into  a  meaning¬ 
ful  form,  and  present  the  information  to  decision  makers  in  a  timely  manner. 

A  theoretical  framework  for  DSS  is  developed  in  Chapter  II.  In  this  chapter,  the 
reader  will  be  familiarized  with  the  general  characteristics  of  a  DSS,  planning  and  building 
a  DSS,  management  role  in  developing  a  DSS,  and  other  DSS  concepts  important  to  the 
research.  Where  appropriate,  specific  applications  from  the  theoretical  understanding  of  a 
DSS  to  the  actual  case  at  SBHACH  are  made.  The  purpose  of  moving  between  theory  and 
practical  application  is  to  demonstrate  the  direction  of  research  followed  in  analyzing  and 
designing  the  DSS  for  SBHACH. 
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C.  METHODOLOGY  AND  OBJECTIVES  OF  RESEARCH 


In  order  to  properly  conduct  the  analysis  and  design  of  a  DSS  for  SBHACH,  a 
structured  approach  was  used  to  elicit  management  information  needs,  analyze  current 
information  systems,  and  design  the  proposed  DSS.  Critical  Success  Factor  (CSF)  inter¬ 
views  were  conducted  to  identify  information  needs,  existing  MIS  were  studied  for  use  by 
the  delivered  product,  and  a  structured  design  methodology  was  implemented  in  designing 
the  proposed  DSS. 

1.  Research  Questions 

The  following  research  questions  were  developed  in  order  to  fulfill  the  goal  of 
this  thesis  as  a  document  from  which  a  useful  DSS  may  be  implemented: 

•  How  should  one  best  determine  Critical  Success  Factors  for  a  large  hospital,  specifi¬ 
cally  Silas  B.  Hays  Army  Community  Hospital  (SBHACH),  Fort  Ord,  California? 

•  What  are  the  Critical  Success  Factors  for  SBHACH? 

•  What  should  a  Decision  Support  System  look  like  in  order  to  support  decision  makers 
in  meeting  these  Critical  Success  Factors? 

•  What  must  be  done  to  build  such  a  Decision  Support  System? 

By  thoroughly  researching  these  questions  and  presenting  the  answers  in  a 
concise  form,  the  goals  of  this  thesis  will  be  satisfied. 

2.  Critical  Success  Factors  (CSFs) 

Chief  executives  are  finding  more  and  more  that  they  are  inundated  with  data  in 
an  unusable  form.  Managers  examine  reports,  determine  what  pieces  of  information  are 
important,  and  take  the  necessary  action  [Rockart  79].  The  same  is  true  for  upper-level 
management  at  SBHACH  [Appendix  A].  The  information  required  to  make  timely  deci¬ 
sions  is  present  in  existing  MIS,  but  not  in  useable  form  to  make  decisions  based  solely  on 
a  single  MIS  output.  The  most  difficult  part  of  analyzing  management  information  needs  is 
eliciting  what  “key  areas”  of  business  activity  are  necessary  to  obtain  good  results  for  a 
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manager  to  reach  established  goals  [Rockart  82],  These  “key  areas”  are  called  Critical 
Success  Factors  (CSFs)  and  are  a  major  concern  for  decision  makers  in  order  to  perform 
well,  regardless  of  the  industry  in  which  they  operate. 

Critical  Success  Factors  are  used  to  generally  describe  what  managers  need  to 
be  concerned  with  in  their  daily  business  functions.  A  more  precise  definition  of  CSFs  is 
found  in  Bullen  and  Rockart’s  article  “A  Primer  on  Critical  Success  Factors,”  defining 
CSFs  as: 

The  limited  number  of  areas  in  which  satisfactory  results  will  ensure  successful  com¬ 
petitive  performance  for  the  individual,  department,  or  organization.  CSFs  are  those 
key  areas  where  “things  must  go  right”  for  the  business  to  flourish  and  for  the  man¬ 
ager’s  goals  to  be  attained  [Bullen  81]. 

Managers  may  not  be  able  to  explicitly  state  exactly  what  their  CSFs  are,  but 
they  know  or  have  a  feeling  for  the  information  they  require  in  order  to  satisfy  these  CSFs. 
Most  managers  have  implicit  CSFs  that  they  have  been  using  without  consciously  knowing 
it  to  help  them  manage.  By  using  a  structured  interview  technique,  implicit  CSFs  are  made 
explicit  [Bullen  81]. 

The  author  conducted  a  series  of  structured  interviews  of  upper-level  manage¬ 
ment  at  SBHACH  using  Appendix  B  as  a  guide.  Synopses  of  interviews  are  contained  in 
Appendix  C,  and  from  these  interviews  CSF  information  needs  were  determined  for  devel¬ 
opment  into  a  DSS.  Chapter  III  provides  a  detailed  analysis  of  CSF  development. 

3.  Existing  Hospital  MIS 

A  DSS  will  draw  upon  existing  MIS  that  have  already  been  developed  in  order 
to  support  identified  information  needs.  After  information  requirements  are  presented,  a 
synopsis  of  in-place  MIS  is  discussed  to  identify  where  data  may  be  obtained  to  satisfy 
user  needs. 

SBHACH  has  in  place  approximately  five  different  stand-alone  MIS.  During 
the  course  of  research  it  was  necessary  to  study  the  existing  MIS  to  determine  what 


information  is  collected  and  the  fonn  it  is  in.  This  research  was  done  through  interviews  of 
information  systems  personnel  at  SBHACH  (summarized  in  Appendix  D)  and  MIS  docu¬ 
mentation  studies.  Chapter  III  also  provides  a  detailed  analysis  of  this  portion  of  the 
research. 

4.  Structured  Analysis  and  Structured  Design  Methodology 

Structured  Analysis  and  Structured  Design  use  a  systematic  approach  to  develop 
a  software  product  that  is  maintainable,  reliable,  and  adaptable  [Page- Jones  80].  By  using 
the  tools  of  this  methodology,  this  thesis  produces  a  properly  documented  software  product 
from  which  a  working  DSS  may  easily  be  implemented. 

Once  CSF  data  were  obtained,  outputs  from  Structured  Analysis  and  Structured 
Design  methodologies  were  developed  and  presented  in  Chapter  IV.  The  deliverables  from 
this  method — Data  Flow  Diagrams  (DFDs),  Data  Dictionaries  (DDs),  structure  charts, 
mini-specifications,  and  module  specifications — are  presented  in  the  appendices  as  docu¬ 
mentation  for  the  DSS.  These  outputs  will  allow  information  systems  personnel  to  easily 
implement  the  designed  DSS. 

The  different  stand-alone  MIS  at  SBHACH  run  on  different  and  sometimes 
incompatible  hardware.  The  programs  are  written  in  different  programming  languages  and 
supported  by  civilian  contract  personnel.  Integration  of  software  modules  developed  by 
SBHACH  personnel  into  the  different  stand-alone  systems  to  extract  data  was  ruled  out  due 
to  possible  violation  of  existing  commercial  contracts.  Chapter  IV  describes  the  approach 
taken  to  remove  needed  data  from  the  different  MIS  to  support  the  designed  DSS. 

D.  ASSUMPTIONS  AND  LIMITATIONS  OF  RESEARCH 

The  scope  of  the  thesis  was  limited  in  size  to  accommodate  an  adequate  amount  of 
proposed  measures  to  satisfy  CSFs  and  still  provide  a  useful  product.  The  proposed  mea¬ 
sures  incorporated  into  the  DSS  were  limited  to  a  manageable  number  for  a  single  thesis 
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student  to  adequately  develop.  Adding  to  the  size  of  the  DSS  by  follow-on  research  is  dis¬ 
cussed  in  the  final  chapter. 

Implementation  was  not  considered  an  overall  goal.  A  thorough  analysis  of  design 
effort  first  must  be  completed.  Further,  SBHACH  information  systems  personnel  are 
better  qualified  to  choose  the  programming  language  with  which  they  wish  to  implement 
the  developed  DSS.  If  they  code  the  DSS,  they  will  more  easily  maintain  the  final  product 
for  future  use  due  to  familiarity  developed  during  the  implementation  phase. 

E.  BENEFITS  OF  RESEARCH 

The  delivered  product  will  provide  documentation  from  which  a  DSS  may  be  imple¬ 
mented.  Once  the  DSS  is  implemented,  it  will  provide  a  significant  increase  in  relevant 
information  flow  to  managers  who  need  it.  This  system  will  quickly  extract  needed  data 
and  manipulate  it  into  a  useable  form  for  presentation  to  decision  makers.  This  aspect  of 
the  system  itself  will  eliminate  the  inordinate  amount  of  time  expended  on  hand  extraction 
of  data  and  consolidation  of  numerous  disjointed  reports. 

Follow-on  research  is  suggested  in  the  area  of  aiding  information  systems  personnel 
in  implementing  the  delivered  product.  A  large  amount  of  coding  and  testing  will  be 
required  before  the  DSS  is  implemented.  Another  area  of  research  to  be  explored  is  the 
continuation  of  CSF  interviews  and  adding  to  the  breadth  of  the  DSS  by  satisfying  more 
information  needs. 

F.  ORGANIZATION  OF  THESIS 

In  this  chapter,  a  brief  introduction  to  the  background  of  the  thesis  and  the  methodol¬ 
ogy  and  objectives  of  the  research  were  presented.  The  reader  was  introduced  to  the  CSF 
interview  technique  to  elicit  information  needs  from  management  personnel  at  SBHACH 
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and  the  proposed  implementation  of  the  delivered  product  by  information  systems 
personnel. 


Chapter  II  establishes  a  theoretical  framework  from  which  the  DSS  is  developed. 
Chapter  II  familiarizes  the  reader  with  the  characteristics  and  purpose  of  a  DSS,  manage¬ 
ment’s  role  in  developing  and  justifying  a  DSS,  planning  and  building  a  DSS,  and  DSS 
architecture  theory. 

Chapters  HI  and  IV  present  the  detailed  analysis  and  design  of  the  SBHACH  DSS. 
Chapter  HI  describes  the  interviews  used  to  analyze  information  needs  of  upper-level  man¬ 
agement.  The  CSFs  are  prioritized  in  this  chapter  and  existing  MIS  details  and  computer 
resources  are  presented  in  detail.  Chapter  IV  provides  the  transformation  of  the  analysis 
conducted  to  the  software  design  of  the  actual  DSS.  The  outputs  of  the  Structured  Analysis 
and  Structured  Design  method  are  formally  presented  from  the  appendices  resulting  in  the 
documentation  of  the  DSS.  Finally,  Chapter  V  summarizes  the  research  conducted  and 
provides  suggestions  for  the  implementation  phase  of  the  delivered  product. 
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II.  DEVELOPING  A  THEORETICAL  FOUNDATION  OF  DECISION 
SUPPORT  AND  DECISION  SUPPORT  SYSTEMS 


In  recent  years,  there  have  been  significant  developments  in  the  Decision  Support 
Systems  (DSS)  field.  A  review  of  pertinent  literature  provides  various  definitions  of  what 
DSS  are  and  how  decision  support  can  aid  decision  makers.  In  this  chapter,  a  relevant 
framework  is  developed  from  publications  by  respected  DSS  researchers.  Where  appro¬ 
priate  in  the  framework  presentation,  a  bridge  between  theory  and  the  proposed  DSS  at 
Silas  B.  Hays  Army  Community  Hospital  (SBHACH)  will  be  made. 

Most  of  the  publications  read  offered  varied  characteristics  of  decision  support  and 
DSS.  The  next  section  presents  characteristics  of  DSS  deemed  most  relevant 

A.  DSS  CHARACTERISTICS 

Decision  support  is  looked  upon  as  an  approach  to  analyzing  complex  organizational 
decision  making  and  the  ways  decision  making  can  be  aided  through  computer  technology. 
In  this  section,  general  definitions  and  DSS  purpose  are  presented,  the  level  of  management 
supported  by  a  DSS  is  discussed,  and  the  relationship  of  Management  Information  System 
(MIS)  technology  to  decision  support  is  identified.  This  provides  the  reader  with  a  better 
understanding  of  the  philosophy  behind  decision  support  and  the  ways  it  can  aid  organiza¬ 
tional  decision  making. 

1.  DSS  Definition  and  Purpose 

Any  discussion  about  DSS  should  start  with  the  differences  in  terminology 
between  a  DSS  and  a  “decision  support  system.”  Huber  explains  that  each  individual  has  a 
personal  decision  support  system,  a  “dss,”  which  is  used  daily  in  organizational  decision 
making.  This  system  uses  various  methods  to  collect  and  categorize  relevant  data  and  uses 


decision  aids  to  examine  possible  outcomes  of  alternatives  analyzed.  In  essence,  managers 
use  a  variety  of  resources  to  ask  “What  if?”  questions  to  decide  on  a  particular  problem 
solution.  A  Decision  Support  System  (DSS)  is  that  part  of  the  personal  decision  support 
system,  a  “dss,”  that  is  automated  or  computer  enhanced  [Huber  81].  A  difference  in 
terminology  is  made  here.  A  “dss”  does  not  have  to  be  automated  by  computer  technology, 
but  a  DSS  takes  advantage  of  the  processing  and  modeling  power  of  computer  technology. 

Keen  summarizes  that  an  important  goal  of  a  DSS  is  for  decision  makers  to 
learn  more  about  the  decision  problem  and  a  DSS  is  suited  to  provide  this  learning  envi¬ 
ronment  [Keen  87].  From  this  summary,  a  DSS  can  be  described  as  a  computer-enhanced 
management  learning  tool  that  aids  decision  makers  in  defining  the  decision  problem  and 
analyzing  possible  alternatives. 

A  broad  definition  of  a  DSS  is  provided  by  Sprague  and  Carlson  in  their  book 
[Sprague  82].  They  define  DSS  as  having  the  following  characteristics: 

•  Computer  based  systems; 

•  That  help  decision  makers; 

•  Confront  ill-structured  problems; 

•  Through  direct  interaction; 

•  With  data  and  analysis. 

This  general  definition  provides  a  useful  “checklist”  with  which  a  DSS  for 
SBHACH  may  be  evaluated  in  later  chapters. 

Ford  presents  a  DSS  as  incorporating  features  from  management  information 
systems,  management  science,  and  operations  research  technologies  into  a  system  that 
draws  upon  all  technologies  for  a  synergistic  effect  [Ford  85].  This  synergistic  whole  of 
man  and  computer  is  much  greater  than  the  sum  of  the  parts — man  and  computer  perform¬ 
ing  decision  making  separately.  An  interactive  computer-based  system  accessing  data 
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databases  and  allowing  decision  makers  to  perform  “What  if?”  analysis  will  achieve  desired 
synergy. 

A  1981  study  of  eight  commercial  DSS  by  Keen  showed  that  different  DSS 
applications  have  many  common  characteristics  but  all  should  have  four  features  to  be  suc¬ 
cessful  [Keen  81].  As  a  minimum,  a  DSS  should  be  the  following: 

•  Flexible  to  handle  different  situations; 

•  Easy  to  use; 

•  Responsive; 

•  Communicative. 

These  four  factors  were  important  to  consider  when  developing  a  DSS  for 
SBHACH  because  ignoring  any  one  of  these  factors  might  cause  the  product  to  lapse  into 
disuse.  The  delivered  product  when  implemented  should  address  several  identified  critical 
problems.  The  DSS  should  be  easy  to  use  for  novices  as  well  as  experienced  computer 
users;  to  encourage  use,  the  DSS  should  also  feature  a  user  dialog  responsive  to  user 
queries. 

This  section  explicitly  points  out  that  DSS  are  developed  to  aid  managers  in 
their  decision  making  tasks.  The  question  arises  then  whether  DSS  should  be  available  for 
all  managers  within  an  organization,  or  whether  DSS  should  be  built  for  a  specific  organi¬ 
zational  management  level.  The  next  section  addresses  this  question  about  which  managers 
within  an  organization  a  DSS  should  support. 

2.  Level  of  Management  Supported  By  a  DSS 

Ackoff  explains  that  a  DSS  tends  to  be  used  for  semi-structured  and  ill-struc¬ 
tured  problems.  He  points  out  that  these  less-structured  problems  are  commonly  faced  by 
upper- level  managers  [Ackoff  67],  Lower-level  managers  deal  with  more  structured  prob¬ 
lems  that  have  known  solutions  and  thereby  make  a  DSS  difficult  to  cost  justify. 


Alexander  echoes  the  level  of  management  supported  by  pointing  out  that  a  DSS  should 
provide  relevant,  boiled-down  data  to  senior  managers  or,  simply,  high-level  information 
for  high-level  people  [Alexander  86],  Sprague  states  that  upper-level  managers  usually 
deal  with  less  structured  problems  and  a  DSS  can  provide  needed  information  for  decision 
making  [Sprague  86]. 

The  proposed  DSS  is  intended  for  use  by  senior  resource  managers  at 
SBHACH.  The  DSS  will  provide  these  upper-level  mangers  with  relevant  information  to 
address  the  ill-structured  problems  they  face.  Chapter  ID  provides  more  detail  in  identify¬ 
ing  which  managers  the  DSS  will  support  at  SBHACH. 

3.  MIS  Versus  DSS 

A  review  of  the  literature  brought  out  some  important  concepts  about  the  rela¬ 
tionship  between  MIS  and  DSS  technologies.  It  is  important  to  present  an  MIS  and  DSS 
overview  to  discuss  their  interaction  with  one  another,  and  specifically  how  MIS  can  sup¬ 
port  DSS,  differences  in  the  types  of  management  problems  supported  by  each  technology, 
and  the  separation  of  decision  making  and  information  gathering.  These  distinctions  will 
be  key  in  defining  how  the  MIS  at  SBHACH  will  be  used  in  conjunction  with  the  designed 
DSS. 

a.  MIS  Support  of  DSS 

Due  to  the  many  existing  stand-alone  MIS  at  SBHACH,  it  is  necessary  to 
discuss  how  an  MIS  is  used  in  relation  to  a  DSS.  Alexander  proposes  that  an  MIS  sup¬ 
ports  a  DSS  in  that: 

A  DSS  does  not  replace  or  compete  with  other  systems;  instead,  it  extracts  from  other 
systems  the  information  that  is  essential  to  the  process  of  decision  making. 
[Alexander  86] 

Figure  2-1  graphically  depicts  a  DSS  acting  as  an  intermediaiy  between 
user  and  data  sources.  The  DSS  accesses  the  different  MIS,  manipulates  the  data,  and 
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selectively  presents  the  processed  information  to  users.  Chapter  m  provides  a  specific 
description  of  how  existing  MIS  at  SBHACH  will  support  the  developed  DSS. 


Figure  2-1.  Management  Information  Systems  (MIS)  in  Relation  to  Decision 

Support  Systems  (DSS) 

As  discussed  earlier,  DSS  are  used  to  support  upper-level  managers  con¬ 
fronted  by  ill- structured  problems.  This  next  section  differentiates  the  varied  levels  of 
problem  structure  facing  different  levels  of  managers  and  which  technology,  MIS  or  DSS, 
is  best  suited  for  implementation  in  the  different  cases. 

b.  MIS  and  DSS  Problem  Structure 

MIS  and  DSS  are  developed  to  support  different  types  of  management 
problems  within  an  organization.  The  different  types  of  problems  to  be  discussed  range 
from  structured  to  unstructured  problem  areas.  Figure  2-2  shows  the  different  levels  of 
problem  structures  within  an  organization;  inside  each  cell  are  types  of  sample  management 
problems  faced  by  decision  makers.  These  problem  types  are  not  always  clear  cut  and  tend 
to  be  less  defined  categories  [Gorry  71].  According  to  Gorry  and  Scott  Morton,  a  nebu¬ 
lous  dividing  line  at  the  semi- structured  decision  level  can  be  drawn  separating  the  figure 
into  two  areas:  structured  or  unstructured  problems.  These  two  areas  are  not  well  defined 
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on  the  fringes  of  the  separation  but  represent  levels  of  problem  structure  tending  to  be  sup- 
prated  by  either  MIS  or  DSS  applications. 
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Figure  2-2.  Different  Levels  of  Decision  Making  Supported  by  Management 
Information  System  (MIS)  or  Decision  Support  System  (DSS)  Technologies 


A  management  problem  is  considered  structured  if  it  is  repetitive,  routine, 
and  most  of  the  decision  making  process  may  be  automated.  An  unstructured  problem  is  a 
novel,  new  problem  that  has  not  been  faced  by  managers  before  [Simon  60].  Structured 
and  unstructured  problems  differ  in  their  requirements  for  information  and  computer 
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support. 


The  upper  half  of  Figure  2-2  deals  with  structured  problems  and  informa¬ 
tion  needs  for  structured  problems.  Because  these  problem  types  have  little  to  do  with  real 
information  management,  they  are  best  satisfied  by  MIS  or  data-processing  technologies. 
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The  area  below  the  separation  contains  more  complex  variables.  These  unstructured  prob¬ 
lem  areas  are  best  addressed  using  DSS  capabilities  [Gorry  71]. 

In  essence,  MIS  are  used  to  support  lower-level  managers  who  deal  with 
more  routine  or  structured  decision-making  tasks.  On  the  other  hand,  DSS  aid  upper-level 
managers  when  faced  with  non-routine  or  unstructured  decision  making  tasks. 

c.  Information  Gathering  and  Decision  Making  Separation 

The  previous  sections  discussed  the  different  purposes  of  MIS  and  DSS 
technologies  in  relation  to  the  level  of  management  supported  and  the  structure  of  problems 
addressed.  This  section  provides  a  differentiation  between  MIS  and  DSS  in  relation  to 
gathering  information  and  decision  making. 

It  is  important  to  define  at  what  point  in  the  decision  process  an  MIS 
leaves  off  and  a  DSS  picks  up.  The  decision  process  is  a  combination  of  the  information 
system  and  the  decision-making  system.  The  information  system  is  the  process  through 
which  data  is  collected  and  stored.  The  decision-making  system  is  the  actual  person  or 
persons  responsible  with  analyzing  the  information,  analyzing  alternatives  based  on  data 
presented,  and  choosing  an  alternative.  The  entire  decision  process  deals  with  collecting 
data  from  various  sources,  making  predictions  and  drawing  inferences  from  the  data, 
assigning  values  from  inferences  drawn,  and  taking  action.  Figure  2-3(a)  depicts  the 
sequence  of  events  from  data  collection  to  action  taking  that  combine  the  information  and 
decision-making  systems  into  the  decision  process  [Mason  81]. 

Figure  2-3(b)  represents  support  an  MIS  lends  to  the  decision  process. 
The  information  system  is  tasked  with  storing,  retrieving,  and  classifying  potentially  useful 
data  for  the  decision-making  system.  The  decision-making  system  then  determines  from 
which  areas  the  data  must  be  retrieved  and  makes  these  requests  to  the  information  system. 
Mason  points  out  that  it  is  not  feasible  for  the  information  system  to  have  the  capability  of 


retrieving  all  combinations  and  permutations  of  possible  requests.  Therefore,  the  decision 
system  is  tasked  with  generating  these  requests,  drawing  inferences  and  predictions  from 
delivered  reports,  assigning  values,  and  choosing  a  course  of  action.  Figure  2-3(b)  repre¬ 
sents  the  MIS  level  of  support  present  at  SBHACH. 
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(b)  MIS  Support  of  Decision  Process 
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(c)  DSS  Support  of  Decision  Process 
Figure  2-3.  MIS  and  DSS  Support  of  Decision  Process 

The  designed  DSS  for  SBHACH  will  go  a  step  beyond  the  MIS  level  and 
provide  predictive  information  to  decision  makers.  Figure  2-3(c)  combines  the  ability  to 
make  predictions  and  draw  inferences  from  the  data.  In  this  manner,  the  decision-making 
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system  can  ask  “What  if?”  questions  and  get  appropriate,  timely  responses  from  the  infor¬ 
mation  system.  The  decision-making  system  then  assigns  values  to  possible  choices  and 
takes  action.  As  will  be  seen  in  Chapter  III,  Figure  2- 3(c)  represents  the  separation  of  the 
information  and  decision-making  systems  for  the  SBHACH  DSS. 

B .  PLANNING  AND  BUILDING  A  DSS 

So  far,  definitions  of  a  DSS  and  how  one  can  support  an  organization’s  decision¬ 
making  process  have  been  provided  along  with  the  differences  between  MIS  and  DSS 
technologies.  This  section  will  now  present  different  development  methods  that  are  used 
for  planning  and  building  DSS. 

Historically,  the  methodology  used  by  systems  analysts  to  develop  computer  software 
has  been  the  systems  development  life  cycle  (SDLC)  process.  As  a  system  is  conceived 
and  moves  from  idea  conception  to  implementation,  it  must  pass  through  several  steps. 
Davis  describes  a  typical  SDLC  in  Figure  2-4  [Davis  83]. 


Figure  2-4.  Classic  Systems  Development  Life  Cycle  Waterfall  Model 


When  this  structured  approach  is  used,  an  analyst  must  start  with  problem  definition 
and  methodically  progress  from  one  step  to  the  next.  As  specific  requirements  for  each 
step  are  completed,  the  development  moves  to  the  next  step,  with  overlap  occurring 
between  steps  [Davis  83].  For  the  most  part,  specific  requirements  must  be  met  during 
each  step  before  system  evolution  can  progress  to  the  next  step.  This  approach  of  system¬ 
atically  moving  through  the  life  cycle,  although  a  disciplined  practice  for  systems  develop¬ 
ment,  is  not  appropriate  to  the  development  of  a  DSS. 

A  typical  system  can  be  developed  using  the  steps  in  Figure  2-4  because  at  the  begin¬ 
ning  of  the  life  cycle,  the  problem  can  be  isolated  by  a  skilled  systems  analyst  and  defined 
to  a  degree  necessary  to  begin  the  remaining  steps.  Unlike  this  approach,  a  DSS  cannot  be 
well  defined  at  the  beginning.  Analysts  and  designers  have  difficulty  in  eliciting  manage¬ 
ment  information  needs  because  decision  makers  cannot  define  in  advance  what  the  system 
should  do.  Planning  and  building  a  DSS  is  not  just  purchasing  hardware  and  developing 
software  to  support  decision  makers.  It  is  planning,  designing,  and  studying  the  organiza¬ 
tion’s  decision  making  processes  [Alexander  86].  There  are  different  methods  of  studying 
this  decision  making  process  and  constructing  a  DSS,  of  which  two  will  be  presented  here. 

1.  DSS  Building  Methods 

The  two  DSS  building  methods  presented,  though  not  always  distinct,  are  dis¬ 
cussed  to  develop  a  flavor  for  the  complex  approach  of  constructing  a  DSS.  The  two 
approaches  are  the  iterative  and  the  adaptive  methods.  The  major  similarities  and  the  minor 
differences  of  the  iterative  and  adaptive  methods  are  presented  to  introduce  an  alternative 
building  method  to  the  SDLC  methodology. 
a.  Iterative  Method 

The  iterative  approach  to  DSS  development  combines  the  first  several 
steps  in  Figure  2-4.  It  is  a  building  block  approach  that  the  DSS  builder  uses  to  meet  actual 
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user  requirements.  A  sub-problem  is  agreed  upon  between  user  and  developer,  a  system  is 
designed  to  satisfy  this  sub-problem,  and  the  system  is  presented  to  the  user  for  feedback. 
The  builder  makes  necessary  corrections  and  continues  the  process  by  building  onto  the 
existing  system.  This  loop  is  repeated  several  times.  As  the  product  is  added  to  and 
revised,  the  user  is  involved  with  the  builder  continuously  to  provide  constant  feedback 
[Sprague  80].  Figure  2-5  demonstrates  the  iterative  process  between  the  builder  and  user. 


ITERATION  OF  DSS 
FOR  USER  REVIEW 


Figure  2-5.  User/Builder  Relationship  of  Iterative  Development  Method 

The  product  is  never  really  Finished,  but  the  frequency  of  loops  decreases 
until  a  useable  product  finally  stabilizes  for  use.  This  approach  is  different  from  prototyp¬ 
ing  in  that  the  first  deliverable  is  a  useable  system  and  not  a  test  case.  The  deliverable  may 
not  perform  all  functions  the  user  requires,  but  it  can  be  iteratively  built  upon  to  encompass 
a  great  deal  of  user  requirements.  The  iterative  method  incorporates  the  first  steps  of  the 
SDLC  method  shown  in  Figure  2-4  into  a  large  feedback  cycle.  The  concentration  is  on  the 
link  established  between  the  user  and  the  builder.  The  adaptive  method,  on  the  other  hand, 
focuses  on  three  links. 

b.  Adaptive  Method 

The  adaptive  method  is  very  similar  to  the  iterative  method  in  that  it  also 
combines  several  steps  of  the  systems  development  life  cycle  method.  The  adaptive 
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approach  uses  feedback  from  the  user  to  build  upon  and  change  the  product  to  user  specifi¬ 
cations  as  demonstrated  in  Figure  2-5,  but  also  incorporates  two  other  links.  This  adaptive 
approach  focuses  on  three  elements  involved  in  building  a  DSS  as  shown  in  Figure  2-6  and 
concentrates  on  the  three  links  between  these  elements  in  developing  the  product  [Alavi 
84]. 


Figure  2-6.  Adaptive  Elements  of  DSS  Development 

The  user-system  link  deals  with  studying  the  effects  a  user’s  characteris¬ 
tics  will  have  on  operating  the  DSS.  This  area  includes  user  cognitive  styles  addressed 
later  in  this  chapter,  experience  and  background  of  computer  use,  and  user  problem-solving 
techniques.  This  link  is  important  to  make  and  establishes  who  will  be  using  the  DSS  and 
what  their  attitudes  are  towards  computing.  This  link  takes  into  account  the  dialog  existing 
between  user  and  DSS  and  the  effect  it  has  on  the  user. 

The  system-builder  link  involves  the  flexibility  of  system  architecture.  It 
allows  the  addition  of  features  and  changes  to  existing  ones  to  accommodate  added 
capabilities.  These  changes  should  be  made  without  undue  time  and  resource  expenditures. 
As  a  builder  understands  more  of  the  user’s  needs  and  the  user  understands  more  of  what  a 
DSS  can  do,  incorporating  this  new  knowledge  quickly  and  efficiently  into  the  DSS  will 
further  enhance  the  delivered  product. 


Finally,  the  user-builder  link  is  the  communication  link  necessary  to 
develop  the  DSS.  This  collaboration  allows  the  user  to  learn  about  the  power  decision 
support  can  give  to  the  decision  maker  and  allows  the  builder  to  learn  about  user  require¬ 
ments  and  build  credibility  [Alavi  84]. 

Similar  to  the  iterative  method,  the  builder  and  user  agree  upon  a  sub¬ 
problem  of  user  requirements  to  be  incorporated  into  the  DSS.  The  builder  constructs  a 
rough  product  of  the  DSS  to  satisfy  this  sub-problem  and  presents  the  product  to  the  user 
for  review.  The  difference  between  the  adaptive  and  iterative  methods  is  the  builder’s 
focus  on  the  relationships  between  builder,  user,  and  system.  The  adaptive  method  explic¬ 
itly  studies  the  unique  relationships  described  above  and  uses  these  three  links  to  build  the 
first  draft  and  incorporate  user  changes. 

This  section  touched  upon  the  level  of  involvement  and  importance  in  the 
relationship  between  the  user  and  builder.  The  next  section  deals  with  the  important  issue 
of  the  ways  users  should  be  involved  in  the  DSS  development  and  the  role  managers  play 
in  developing  DSS  falling  under  their  span  of  control. 

C.  MANAGEMENT  ROLE  IN  DEVELOPING  A  DSS 

All  managers  are  tasked  with  monitoring  and  reviewing  projects  under  their  control. 
A  DSS  is  developed  to  provide  decision  support  for  a  specific  manager  or  group,  and  con¬ 
sequently  falls  under  the  control  of  those  supported  by  the  DSS  [Hogue  83].  Keen  states 
that  a  DSS  is  built  from  a  manager’s  perspective  based  on  his  conception  of  the  decision 
process  and  organization  [Keen  80].  Therefore,  it  is  important  the  user/manager  is  actively 
and  constantly  involved  in  the  control  and  development  process  of  a  DSS. 

1.  User/Management  Involvement 

Within  an  organization,  usually  one  person  or  department  recognizes  informa¬ 
tion  needs  and  that  a  DSS  may  satisfy  these  information  requirements  [Young  84],  Young 
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points  out  it  is  essential  that  an  individual  knows  a  DSS  can  provide  decision  support  for 
the  organization  and  the  individual  is  in  a  management  position  to  power  the  decision  to 
develop  the  DSS. 

As  suggested  in  the  iterative  and  adaptive  design  methodologies,  the  develop¬ 
ment  effort  should  be  a  constant  feedback  loop  between  user  and  builder.  The  user  must  be 
involved  from  inception  to  delivery  to  ensure  user  requirements  are  satisfactorily  met  and 
critical  information  needs  are  satisfied  [Hogue  84].  A  study  of  18  DSS  by  Hogue  and 
Watson  revealed  that  management  control  by  the  requesting  users  was  accomplished 
through  user  involvement,  review  of  developed  products,  and  documentation  [Hogue  83]. 
Review  points  were  established  for  the  user  to  review,  approve,  and  document  the  product 
as  it  was  submitted  iteratively  by  the  builder.  As  the  DSS  moves  toward  completion,  users 
provide  a  constant  source  of  input  and  review.  It  would  appear  that  the  more  users  are 
actively  involved  in  the  DSS  development,  the  more  the  DSS  will  be  accepted.  Users  will 
develop  an  “ownership”  in  the  DSS  and  aid  in  the  development  effort.  User  expectations 
will  be  managed  better  in  that  the  user  will  periodically  review  DSS  progress  and  witness 
how  the  DSS  will  incorporate  user  requirements.  The  proposed  method  of  user  involve¬ 
ment  at  SBHACH,  which  is  a  combination  of  the  iterative  and  adaptive  design  methodolo¬ 
gies,  will  be  discussed  in  Chapter  HI  in  more  detail. 

D.  ARCHITECTURE  OF  A  DSS 

So  far  in  this  chapter,  less  tangible  DSS  concepts  have  been  presented,  such  as  how 
DSS  will  aid  decision  makers,  how  decision  makers  should  be  involved  in  the  DSS  devel¬ 
opment  process,  and  the  structure  of  management  problem  areas  best  addressed  by  a  DSS. 
It  is  now  important  to  describe  the  more  tangible  components  comprising  a  DSS  and  how 
these  components  interact.  Figure  2-7  presents  the  three  components  of  a  DSS  [Sprague 
82]. 
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DSS 


Figure  2-7.  DSS  Sub-Components 


As  shown  in  Figure  2-7,  the  user  accesses  the  DSS  through  a  dialog  interface  which 
drives  the  system  by  chauffeuring  the  decision  maker  through  data  extraction  from 
databases,  data  manipulation  by  models,  and  presentation  of  results  for  decision  making 
[Sprague  87].  By  breaking  a  DSS  down  into  the  database,  modeling,  and  dialog  compo¬ 
nents,  a  builder  can  identify  the  requirements  each  component  must  possess  to  construct  a 
DSS. 

1.  Database  Component 

The  evolution  of  database  technology  in  the  past  decade  has  made  the  addition 
of  this  component  possible  for  use  in  a  DSS  integrated  with  the  other  components.  The 
growth  has  moved  from  performing  transaction  processing  and  file  management  to  adopt¬ 
ing  a  database  management  approach  with  query  languages  to  provide  ad  hoc  reporting 
[Sprague  87]. 
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a.  Description 

Decision  makers  often  rely  not  only  on  internal  data  but  on  external  data  as 
well.  The  database  component  must  extract  and  manage  data  from  both  sources  as  neces¬ 
sary  to  support  user  information  requirements. 

The  database  component  must  provide  memory  storage  for  extracted  data 
prior  to  use,  and  data  generated  as  output  from  modeling  components.  These  storage  and 
retrieval  functions  should  be  fast  and  transparent  to  the  user  [Sprague  82].  Another 
important  characteristic  the  database  component  should  possess  is  the  ability  to  act  as  an 
intermediary  between  different  models.  The  output  from  one  model  may  be  stored  and 
used  alone  or  combined  with  other  model  outputs  as  inputs  to  a  second  model  and  so  on. 

The  data  extraction  system  shown  in  Figure  2-8  [Sprague  82]  functions  as 
a  data  reduction  tool  to  screen  out  superfluous  data.  It  also  serves  to  simplify  the  design  of 
the  DSS  as  well  as  collect  and  maintain  data  for  use  by  the  DSS.  The  separation  of 
operational  and  DSS  databases  allows  faster  incorporation  of  added  user  requirements  and 
responses  to  unanticipated  requests  [Sprague  87].  Chapter  IV  describes  the  databases  that 
will  need  to  be  created  making  up  the  database  component  of  the  DSS  for  SBHACH. 


Figure  2-8.  DSS  Sub-Components  With  Data  Extraction  System 
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2.  Modeling  Component 

The  power  of  a  DSS  relies  upon  its  ability  to  integrate  data  with  models  to 
manipulate  information  into  a  form  useable  by  decision  makers.  The  modeling  component 
is  discussed  to  introduce  the  concept  of  modeling  and  the  way  modeling  plays  an  important 
role  in  decision  support. 

a.  Description 

As  described  earlier,  the  database  component  provides  access  to  the  large 
amount  of  raw  data  necessary  for  decision  making.  However,  it  is  the  modeling  compo¬ 
nent  that  gives  decision  makers  the  ability  to  analyze  this  raw  data  [Sprague  82].  The 
modeling  component  acts  as  a  tool  to  manipulate  data  into  a  meaningful  form  for  decision 
makers.  Sprague  and  Carlson  suggest  the  modeling  component 

provide  a  set  of  mechanisms  for  the  use  of  decision/analysis  models  which  draw  on 
the  data  base  and  are  closely  related  to  it  It  must  also  provide  the  dialog  mechanisms 
for  the  decision  maker  to  interact  with  the  data  and  models  in  a  convenient,  supportive 
manner.  [Sprague  82] 

Use  of  model  output  as  other  model  input  was  mentioned  earlier.  Each 
model  usually  requires  data  in  its  own  format  and  supports  only  one  distinct  phase  of  deci¬ 
sion  making.  It  is  important  that  the  model  component  maintain  a  model  base  that  contains 
a  library  of  models.  Models  that  are  generic  can  be  used  repeatedly  by  the  DSS  and  other 
DSS  [Gorry  71].  Users  find  generic  models  easier  to  use  due  to  the  familiarity  that  comes 
with  frequent  use.  A  decision  maker  should  be  able  to  combine  different  models  in  a  man¬ 
ner  to  manipulate  data  in  support  of  a  variety  of  decision  problems. 

Barbosa  and  Hirko  present  four  characteristics  that  modeling  components 
should  possess  [Barbosa  80].  To  provide  an  enriched  tool  to  the  DSS,  modeling  should 
possess  the  following: 

•  System  interfacing; 

•  User  control; 


•  Flexibility; 

•  Feedback. 

Interfacing  allows  the  user  to  move  in  the  DSS  problem-solving  environ¬ 
ment  without  the  needless  interruption  of  interactively  supplying  too  many  parameters  and 
variables  to  different  models.  The  control  the  user  should  possess  is  found  in  manual  ver¬ 
sus  automatic  modes  of  operation.  The  user  can  manually  select  the  algorithmic  operation 
necessary  to  perform  desired  functions  and  operate  in  the  modeling  system  as  slowly  as 
necessary  to  learn  operating  skills.  By  combining  manual  with  automatic  user  operation, 
the  modeling  component  will  possess  the  flexibility  necessary  to  flow  outputs  of  one  model 
as  inputs  to  another  in  order  to  achieve  desired  results.  Finally,  feedback  to  the  user  is 
necessary  to  maintain  control  over  the  modeling  process.  The  feedback  should  inform  the 
user  what  state  the  solution  generation  is  in  at  all  times  [Barbosa  80]. 

Brennan  and  Elam  noted  that  modeling  for  DSS  use  has  progressed  at  a 

modest  rate  and  the  emphasis  must  be  put  into  “smart”  modeling  [Brennan  85].  The  DSS 

must  have  a  user  interface  when  viewing  the  results  of  the  model  in  an  environment  or 

framework  that  makes  sense  to  the  user.  The  interface  must  not  only  provide  the  results 

from  model  manipulations  but  also  answer  the  question  “Does  the  model  produce  sensible 

results?”  in  order  to  gain  the  trust  of  DSS  users.  Sprague  and  Carlson  echo  this  finding  by 

describing  the  lack  of  trust  DSS  users  experience  with  large  complex  models. 

Decision  makers  do  not  put  a  great  deal  of  faith  in  the  results  of  complex  models  they 
do  not  understand  the  workings  of,  and  major  decisions  may  not  be  entrusted  to 
modeling  components  if  this  trend  prevails.  [Sprague  82] 

Although  modeling  is  a  vitally  important  function  in  manipulating  large 
amounts  of  data,  it  is  virtually  transparent  to  the  user.  The  dialog  component,  although  just 
as  important  as  modeling,  is  not  transparent  and  is  always  in  plain  view  of  the  DSS  user. 


3.  Dialog  Component 

The  last  component  of  the  DSS,  the  dialog  component,  is  vitally  important  in 
that  the  user  sees  this  feature  of  the  DSS  most  often  and  forms  opinions  of  like  or  dislike  of 
the  system  as  a  whole  based  on  this  interaction.  This  component  provides  the  DSS  user 
interface.  According  to  Keen,  “from  a  user’s  perspective,  the  quality  of  the  DSS  largely 
depends  on  the  quality  of  the  dialog.”  [Keen  80]  To  foster  flexibility  of  DSS  use,  the  dia¬ 
log  component  should  cater  to  both  novice  and  experienced  users  [Sprague  80],  This 
flexibility  is  important  due  to  the  turnover  rates  and  shuffling  of  personnel  common  in  mil¬ 
itary  units.  The  DSS  should  provide  the  capability  of  guiding  the  novice  user  through  the 
system  when  the  user  is  changed  to  a  new  job  using  a  DSS  or  temporarily  filling  a  position 
for  a  short  time. 

a.  Description 

The  dialog  component  can  be  broken  down  into  three  elements  that 
collectively  make  up  the  system  interface  of  the  DSS.  As  shown  in  Figure  2-9  [Sprague 
80],  the  dialog  component  is  made  up  of  the  action  language,  the  presentation  language, 
and  the  user  knowledge  base  [Bennet  77]. 

The  action  language  is  the  hardware  and  software  capabilities  the  system 
incorporates  for  the  user  to  communicate  to  the  DSS.  It  may  consist  of  a  keyboard,  mouse, 
light  pen,  voice  command,  or  other  means  necessary  for  the  DSS  to  be  used.  The  devel¬ 
opment  of  the  action  language  should  be  dependent  on  user  input  skills  with  various  hard¬ 
ware  methods.  The  existing  hardware  and  software  within  the  organization  must  also  be 
taken  into  account  if  the  DSS  is  to  be  developed  to  run  on  those  components. 

The  presentation  language  is  the  means  by  which  the  output  is  displayed 
to  the  user  of  the  DSS.  It  is  the  method  by  which  the  output  is  written  or  graphically  dis¬ 
played  on  the  computer  screen.  The  presentation  language  is  an  important  aspect  of  the 


system  because  users  have  different  cognitive  styles.  The  importance  of  realizing  this  style 
difference  and  not  attempting  to  incorporate  user  cognitive  style  in  a  DSS  is  discussed  later 
in  this  chapter. 
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Figure  2-9.  The  User  System  Interface 


The  knowledge  base  is  what  the  user  must  know  to  operate  the  system. 
This  knowledge  base  may  be  inherent  to  the  user  or  in  a  user  manual,  help  keys,  or  note 
cards.  The  success  of  a  DSS  is  often  evaluated  by  whether  it  is  used.  Developing  a  dialog 
component  that  is  easily  understood  and  useable  by  novice  and  experienced  users  alike  will 
produce  a  product  that  will  be  used  by  decision  makers. 
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b.  Constructing  the  Dialog  Component 

When  developing  a  DSS  for  an  organization,  it  is  important  to  factor  in  the 
three  elements  of  the  dialog  component  for  analysis.  This  is  done  by  a  skilled  analyst 
through  interviews  and  studies  of  existing  databases  and  hardware  components.  After 
analysis  is  complete,  the  DSS  builder  should  have  an  idea  of  the  skill  level  DSS  users  pos¬ 
sess  and  what  hardware  will  be  available  to  run  the  implemented  DSS. 

At  the  completion  of  interviews,  the  DSS  builder  will  have  a  framework 
from  which  to  develop  the  action  and  presentation  languages.  The  action  language  can  be 
determined  early  in  the  development  process  by  studying  decision  makers  at  work  with 
existing  computer  resources  and  taking  informal  surveys  of  skill  levels.  The  hardware  on 
which  the  DSS  will  operate  often  dictates  the  extent  of  the  action  language  to  be  used. 
Determining  the  actual  information  to  be  presented  to  the  decision  maker  determines  the 
mode  in  which  the  information  will  be  presented.  If  DSS  users  require  a  variety  of  infor¬ 
mation  for  forecasting  and  comparing  trends  within  sub-units  of  the  organization,  then 
graphic  capabilities  will  be  required.  Presentation  requirements  are  addressed  later  in  this 
chapter.  Interviews  are  a  good  source  for  identifying  how  much  the  knowledge  base 
should  rely  on  the  user  and  how  much  should  be  incorporated  internal  to  the  DSS  and 
documentation. 

Using  an  iterative  approach  by  developing  a  small  sub-problem  of  the 
DSS  and  submitting  it  to  the  user  for  his  critique  will  have  a  positive  effect  on  the  develop¬ 
ment  of  the  DSS.  Primarily,  it  will  provide  a  walk-through  using  sample  input  and  output 
so  the  user  becomes  familiar  with  what  the  DSS  will  be  like.  The  second  effect  is  testing 
the  user  under  field  conditions.  The  builder  can  actually  observe  the  user  and  find  out 
where  problem  areas  exist  (e.g.,  data  entry  error  rates)  and  make  adjustments  to  the  dialog 
component  accordingly  [Sprague  82]. 
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Sprague  and  Carlson  list  several  examples  of  dialog  styles  that  could  be 
employed  by  a  DSS  [Sprague  82].  These  examples  range  from  the  basic  one-line-at-a-time 
question-answer  dialogs  (Q/A),  to  progressive  menu  selection  dialogs,  to  more  complex 
command  language  dialogs.  The  development  of  the  dialog  component  should  thoroughly 
investigate  which  dialog  style  will  best  suit  the  DSS. 

Q/A  dialogs  lead  users  through  the  system  by  presenting  a  series  of  ques¬ 
tions  that  narrow  down  the  scope  until  the  desired  information  view  is  found.  Menu-driven 
dialogs  lead  the  user  through  different  possible  options  available  until  the  desired  informa¬ 
tion  view  is  obtained.  Figure  2-10  provides  an  example  of  the  menu  dialog.  In  this  Figure, 
the  user  is  offered  one  of  four  options.  A  selection  of  menu  options  one,  two,  or  three  will 
present  the  user  with  another  menu  option  screen.  This  method  guides  the  user  through  the 
different  menu  choices  until  the  desired  view  of  the  data  is  found.  Command  language 
dialogs  involve  memorizing  a  series  of  verb-noun  pairs  (a  command)  which  is  typed  into 
the  computer  to  invoke  a  DSS  function.  For  example,  CALC  MCCU  will  calculate  the 
Medical  Care  Composite  Units  (MCCUs)  over  a  given  period  of  time. 

PLEASE  CHOOSE  THE  NUMERIC  OPTION  CORRESPONDING  TO 

YOUR  DESIRED  MENU  SELECTION. 

1 .  Calculate  Medical  Care  Composite  Units  (MCCUs). 

2.  Graph  historic  Medical  Care  Composite  Units  (MCCUs). 

3.  Perform  Medical  Care  Composite  Unit  (MCCU)  sensitivity  analysis. 

4.  Exit  the  DSS. 

PLEASE  CHOOSE  A  NUMERIC  OPTION  1  TO  4  . . .  _ 


Figure  2-10.  Sample  Menu  Option  Display 


In  determining  the  appropriate  dialog  level,  one  factor  considered  often  is 
frequency  of  use.  The  frequent  user  will  eventually  find  the  Q/A  dialog  style  tedious  and 
prefer  the  command  dialog.  Conversely,  the  infrequent  user  will  see  the  Q/A  dialog  more 
accommodating  since  the  command  language  dialog  involves  constant  relearning  of  com¬ 
mands.  Given  the  current  problem  environment,  both  user  types  could  be  expected  to  use 
the  DSS.  The  menu-driven  method  should  combine  the  respective  advantages  from  the 
Q/A  and  command  dialog  styles  that  would  benefit  users.  A  number  of  alternatives  are 
presented  to  the  user  on  screen.  Selection  is  made  from  these  on-screen  choices,  thereby 
eliminating  the  need  to  memorize  commands  and  the  line-by-line  process.  A  hierarchy  of 
menus  could  be  devised  to  provide  a  wide  range  of  alternative  displays. 

The  analysis  of  an  organization  to  determine  the  content  of  the  DSS  archi¬ 
tecture  requires  a  substantial  allotment  of  time  and  other  resources.  Managers  need  some 
type  of  tool  to  determine  whether  construction  of  a  DSS  be  undertaken.  The  next  section 
addresses  the  method  to  be  used  in  justifying  this  construction. 

E.  JUSTIFYING  A  DSS 

Although  costs  for  computer  hardware  have  been  decreasing  in  recent  years,  alloca¬ 
tion  of  funds  for  capital  ventures  such  as  computer  systems  still  require  a  significant  outlay 
of  resources  for  most  organizations.  For  a  computer  system  to  be  designed,  built,  and 
maintained,  some  method  of  quantifiable  payback  is  required.  Historically,  cost-benefit 
analysis  is  a  tool  used  to  choose  between  competing  capital  decisions  by  eliminating  unde¬ 
sirable  projects  and  highlighting  projects  that  can  be  successfully  undertaken. 

1.  Cost-Benefit  Method 

The  cost-benefit  method,  although  relevant  for  most  system  projects,  is  not  well 
suited  for  DSS  [Keen  81].  For  this  reason,  the  value  analysis  method  is  presented  as  an 
alternative  to  the  cost-benefit  method.  As  Keen  points  out,  DSS  provide  benefits  that  are 
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qualitative  and  not  quantitative.  The  key  failure  of  using  the  cost-benefit  method  to  evaluate 
a  DSS  is  the  inability  to  match  associated  costs  and  benefits  to  the  proposed  DSS. 

The  cost  portion  of  a  DSS  is  difficult  to  accurately  pin  down.  How  does  one 
separate  the  different  costs  associated  with  a  manager’s  time?  The  question  asks  “How 
much  should  be  charged  to  building  the  DSS  with  regard  to  the  cost  of  a  manager’s  time 
used  while  conducting  interviews  and  iterative  reviews  of  the  DSS?”  Also  involved  are 
costs  associated  with  sharing  existing  computer  hardware  and  databases  the  DSS  will 
require.  What  is  a  “fair  share”  of  how  much  of  the  existing  hardware  the  DSS  will  use  on  a 
daily  basis?  This  percentage  is  difficult  to  predict  prior  to  building  a  DSS. 

Hogue  and  Watson  point  out  that  “many  DSS  are  never  finished  but,  continu¬ 
ously  evolve  [Hogue  84].”  This  brings  out  the  question  of  what  the  costs  will  be  with  ad¬ 
ditions  to  the  DSS  and  how  these  costs  will  be  factored  into  the  analysis. 

Benefits  also  present  a  problem  to  managers.  The  benefits  a  standard  computer 
system  gives  to  an  organization  are  quantifiable,  while  the  benefits  a  DSS  provides  are 
mostly  qualitative  in  nature.  Keen  presented  examples  such  as  viewing  more  alternatives 
prior  to  decision  making,  generating  new  ideas,  and  increasing  communication  of  analysis. 
Managers  examining  potential  benefits  of  a  DSS  cannot  easily  quantify  these  features  for 
comparison  against  competing  capital  decisions.  Another  approach  for  analyzing  the  value 
of  a  DSS  is  required.  This  approach  is  the  value  analysis  method. 

2.  Value  Analysis 

Keen  states  that  value  analysis  proposes  a  systematic  means  of  determining  if  a 
cost  is  justified  on  a  product  by  concentrating  on  the  following: 

•  Value  first  then  cost; 

•  Simplicity  and  robustness; 
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•  Reduction  of  uncertainty; 

•  Innovation. 

This  method  allows  projects  to  be  analyzed  that  would  otherwise  be  elimi¬ 
nated — it  focuses  on  the  estimates  decision  makers  will  have  to  provide  to  the  DSS  and 
how  well  it  reduces  the  risk  of  the  situation  and  adds  innovation  rather  than  imposing 
structure  [Keen  81]. 

An  approach  focusing  on  the  four  elements  presented  above  is  used  to  develop 
the  DSS.  Developing  a  working  subset  of  the  DSS  by  incorporating  a  few  of  the  user 
requirements  shows  the  user  what  benefits  he  will  gain  from  the  system  and  relates  these 
benefits  to  a  dollar  amount  spent.  Decision  makers  can  roughly  interpolate  the  cost  of  the 
entire  system,  compare  this  cost  with  the  benefits,  and  determine  whether  the  development 
effort  should  proceed.  This  methodology  is  easily  incorporated  with  the  iterative  and 
adaptive  DSS  building  techniques  and  promises  to  deliver  a  product  for  an  acceptable  cost. 

F .  COGNITIVE  STYLES  OF  DSS  USERS 

As  alluded  to  in  DSS  architecture,  the  presentation  language  the  DSS  uses  may  influ¬ 
ence  the  user’s  decision-making  process.  This  section  of  the  chapter  will  present  two 
important  points  for  discussion  that  should  be  considered  when  designing  a  DSS.  The  two 
points  are  (1)  inconsistency  of  cognitive  styles  between  individuals,  and  (2)  the  effects  of 
presenting  statistics  and  facts  to  users  in  relation  to  decision  making. 

Designing  a  DSS  to  incorporate  a  user’s  cognitive  style,  as  attractive  as  this  may 
seem,  is  not  recommended  by  researchers  [Huber  83  and  Mann  86].  There  are  a  number  of 
reasons  for  not  tailoring  a  DSS  to  fit  the  cognitive  style  of  the  user,  primarily  the  erratic 
cognitive  styles  between  individuals. 


1.  Inconsistency  of  Cognitive  Styles 


Miller  points  out  that  individuals,  when  presented  with  problems  and  alterna¬ 
tives,  tend  to  recode  or  restate  the  presented  information  into  a  form  that  makes  sense  to  the 
individual  [Miller  56].  This  reverbalization  tends  to  draw  upon  the  individual’s  own  per¬ 
sonal  history  and  past  experiences,  thereby  influencing  what  he  perceives  the  problem  to 
be.  It  is  possible  then  that  two  different  individuals  observing  the  same  information  can 
draw  very  different  conclusions.  This  inconsistency  between  individuals  does  not  lend 
very  well  to  testing  an  individual’s  cognitive  style  and  incorporating  it  into  a  DSS. 

Not  only  do  inconsistencies  exist  between  individuals,  but  inconsistencies 
within  the  same  individual  are  evident  when  faced  with  different  types  of  decision  problems 
[Dickson  77  and  Huber  83].  Their  research  indicated  that  the  same  individual  has  a  differ¬ 
ent  cognitive  style  when  faced  with  a  different  type  of  decision.  This  implies  that  to  incor¬ 
porate  a  decision  maker’s  cognitive  style  would  require  an  analysis  of  his  cognitive  styles 
across  different  decision  problems. 

Although  it  is  unwise  to  incorporate  cognitive  styles  into  a  DSS,  other  options 
are  available  from  hardware  and  software  components  that  improve  the  overall  decision¬ 
making  quality.  Using  different  dialog  methods — user-guided  or  system-guided  meth¬ 
ods — can  support  novice  users  and  experienced  users.  A  series  of  experiments  studying 
the  impact  of  user-guided  or  system-guided  dialogs  on  novice  and  experienced  computer 
users  supported  this  point  [Benbasat  81].  Novice  users  had  problems  with  the  user-guided 
dialog  and  felt  a  need  to  be  chauffeured  by  the  system-guided  dialog.  This  indicates  a  need 
for  both  system-guided  and  user-guided  techniques  within  the  dialog  component  of  DSS. 

The  ability  of  DSS  to  provide  different  types  of  graphics  to  users  is  important. 
Benbasat’s  study  also  showed  that  although  graphical  reports  decreased  the  accuracy  of 
reported  data,  subjects  tended  to  request  these  reports  prior  to  decision  making.  Results 
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showed  that,  regardless  of  cognitive  style  of  the  subjects,  data  in  graphical  form  will  be 
widely  requested  from  a  DSS.  It  may  therefore  be  important  to  design  a  DSS  to  show  the 
same  data  in  different  graphical  forms  to  better  enhance  user  understanding  and  decrease 
possible  misperception  of  data  presentation  across  a  variety  of  users. 

2.  Statistic  Presentation  Effects 

A  study  by  Tversky  and  Kahneman  demonstrated  the  effect  framing  decision 
problems  in  different  manners  had  on  the  selection  of  alternatives.  They  showed  that  the 
relative  attractiveness  of  options  varied  when  decision  problems  were  framed  in  different 
manners  [Tversky  81].  By  framing  options  in  a  confusing  manner,  it  is  possible  that  deci¬ 
sion  makers  may  select  an  option  they  would  normally  not  select.  One  of  their  studies  dealt 
with  allowing  subjects  a  chance  to  choose  between  options  that  had  probabilities  of  making 
a  profit.  By  wording  the  options  in  a  confusing  manner,  subjects  were  selecting  options 
they  would  not  normally  choose.  It  is  important  when  developing  a  DSS  that  alternatives 
are  framed  in  an  intuitive  manner,  in  terms  decision  makers  are  familiar  with. 

The  limited  ability  of  humans  to  process  information  is  important  to  consider 
when  designing  the  presentation  language  of  a  DSS.  Miller  uses  the  “magical  number 
seven  plus  or  minus  two”  as  a  general  rule  [Miller  56].  He  points  out  in  his  article  that  the 
human  is  capable  of  processing  a  limited  amount  of  information  at  one  time.  In  presenting 
menu  options  to  users,  a  point  of  diminishing  memory  capacity  is  reached.  Miller  suggests 
that  option  presentation  be  kept  near  the  number  seven. 

Another  related  experiment  conducted  by  Benbasat  dealt  with  the  length  of 
command  words  to  use  in  an  interactive  dialog.  The  study  was  done  to  determine  the  effect 
different  lengths  of  command  words  would  have  on  two  groups  of  subjects.  One  group 
used  command  words  that  were  lengthy  but  was  allowed  to  abbreviate  them  whenever 


possible.  The  second  group  used  abbreviated  command  words  and  was  encouraged  to  type 
out  the  full  word  when  group  members  were  unfamiliar  with  the  abbreviation. 

The  experiment  yielded  two  results.  The  group  using  the  longer  command 
words  had  a  tendency  to  abbreviate  the  commands  as  group  members  became  familiar  with 
the  computer  dialog.  The  second  group  (using  abbreviated  commands)  preferred  to  type 
the  command  word  in  its  entirety  when  group  members  were  unfamiliar  with  the  computer 
dialog  [Benbasat  81].  If  lengthy  command  words  are  incorporated  in  the  user  dialog, 
abbreviation  should  be  allowed  to  cater  to  users  familiar  with  the  system.  If  abbreviated 
command  words  are  used,  they  should  be  long  enough  for  novice  users  to  easily  under¬ 
stand  their  meaning. 

G.  SUMMARY 

In  this  chapter,  a  framework  was  established  to  aid  the  reader  in  developing  an 
understanding  about  decision  support  and  DSS.  Concepts  vitally  important  to  the  research 
were  presented  to  provide  a  clear  understanding  of  the  characteristics  and  purposes  of  a 
DSS,  and  how  to  analyze,  design,  and  build  a  functioning  DSS. 

Characteristics  and  definitions  of  a  DSS  were  cited  from  several  prominent 
researchers.  The  overall  consensus  was  that  DSS  aid  decision  makers  in  confronting  ill- 
structured  problems  using  models  and  data  analysis.  The  aid  DSS  users  received  was  the 
enhancements  of  computer  technology  and,  more  importantly,  the  greater  understanding  of 
the  decision  problem. 

Two  methods  of  planning  and  building  a  DSS  were  presented  as  an  alternative  to  the 
systems  development  life  cycle  method.  The  iterative  and  adaptive  methods,  although 
focusing  on  different  aspects  of  the  decision-making  environment,  had  very  similar  meth¬ 
ods  for  developing  a  DSS.  These  similarities  particularly  concentrated  on  constant 
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involvement  of  the  DSS  user.  Sub-problems  of  the  DSS  were  developed  and  presented  to 
the  user  for  review.  This  feedback  method  was  repeated  until  a  working  DSS  was  refined. 

This  chapter  most  importantly  presented  the  three  components  of  the  architecture  of 
DSS.  The  data,  dialog,  and  modeling  components  are  described  in  Figure  2-11,  which  will 
be  used  in  Chapter  IV  to  develop  the  DSS  components.  These  components  provide  a  con¬ 
cise  schematic  of  the  DSS  structure  for  the  author  to  systematically  begin  analysis  and 
design.  Chapter  II  provided  the  necessary  guidance  to  analyze,  design,  and  build  a  DSS. 
Chapter  HI  will  discuss  the  analysis  phase  of  the  SBHACH  DSS. 
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UL  DERIVATION  OF  CRITICAL  SUCCESS  FACTORS 

A  framework  for  analyzing  and  designing  a  Decision  Support  System  (DSS)  was 
developed  in  Chapter  II.  The  purpose  of  this  chapter  is  to  present  the  derivation  of  Critical 
Success  Factors  (CSFs)  for  Silas  B.  Hays  Army  Community  Hospital  (SBHACH).  The 
organizational  setting  of  SBHACH  is  presented  with  emphasis  on  how  the  proposed  DSS 
will  support  hospital  managers.  The  methodology  used  to  collect  CSF  data  from  hospital 
managers  is  described  and  the  derivation  of  organizational  CSFs  from  collected  data  is  dis¬ 
cussed.  Finally,  the  findings  of  the  CSF  methodology  are  presented,  consisting  of  a  dis¬ 
cussion  of  each  hospital  CSF  and  proposed  measures  for  satisfying  the  CSF. 

A.  SETTING 

In  order  to  gain  an  appreciation  for  the  breadth  and  complexity  of  the  management 
task  facing  the  Hospital  Commander  and  his  staff,  it  is  necessary  to  understand  the  organi¬ 
zational  structure  of  SBHACH.  This  section  describes  the  mission  of  SBHACH,  dis¬ 
cusses  the  chain  of  command,  and  discusses  the  current  methods  administrators  use  to 
manage  hospital  resources,  including  a  description  of  existing  Management  Information 
Systems  (MIS).  As  presented  in  Chapter  II,  DSS  are  best  justified  and  tailored  to  support 
upper-level  managers.  This  section  also  identifies  the  specific  upper-level  management 
positions  in  the  hospital  chain  of  command  that  will  be  supported  by  the  proposed  DSS 
(Resource  Management  DSS). 

1.  Mission  of  SBHACH 

The  mission  of  SBHACH  is  to  provide  quality  health-care  services  to  autho¬ 
rized  personnel  within  the  Fort  Ord  Health  Services  Area.  This  includes  inpatient  and  out¬ 
patient  medical  treatment  to  active  duty  and  retired  personnel,  their  dependents,  and  other 
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personnel  as  authorized  by  the  Department  of  the  Army  [Army  Reg  40-3  85].  This  broad 
mission  statement  neatly  summarizes  the  purpose  of  SBHACH,  but  accomplishing  this  task 
requires  the  combined  efforts  of  many  skilled  health-care  providers  and  resource  managers. 

2 .  Chain  of  Command 

Figure  3-1  [Army  Reg.  40-3  85]  depicts  the  organizational  structure  of  the 
major  internal  departments  of  SBHACH.  The  operational  clinics  and  wards,  consisting  of 
the  departments  of  medicine,  surgery,  psychiatry,  etc.,  are  consolidated  under  the  Deputy 
Commander  for  Clinical  Services,  who  reports  directly  to  the  Hospital  Commander.  Each 
operational  department  is  responsible  for  providing  diagnosis,  care,  and  treatment  in  its 
respective  field  of  medicine.  The  Clinical  Support  Division  aids  the  Deputy  Commander 
for  Clinical  Services  by  providing  budget  planning,  coordination,  preparation,  and 
supervision  [Army  Reg  40-3  85]. 

The  Deputy  Commander  for  Administration  also  reports  directly  to  the  Hospital 
Commander  and  is  the  principal  staff  advisor  to  the  commander  on  management  and 
administrative  matters.  Reporting  to  the  Deputy  Commander  for  Administration  are  several 
miscellaneous  divisions  providing  administrative  record  keeping,  information  reporting, 
and  data  processing  support,  including  the  Resource  Management  Division.  The  Resource 
Management  Division  is  a  primary  source  of  information  the  Deputy  Commander  for 
Administration  uses  to  administratively  monitor  key  areas  within  the  hospital. 

3.  Current  Resource  Management  Methods 

SBHACH  has  several  existing  MIS  in  place  that  contain  data  essential  to  pro¬ 
viding  resource  managers  with  needed  decision-making  information.  This  data  and  data 
from  prepared  reports  are  not  readily  useable;  they  require  processing  prior  to  presentation 
to  decision  makers.  The  current  method  of  obtaining  needed  data  from  the  various 


Figure  3-1.  Silas  B.  Hays  Army  Community  Hospital  Chain  of  Command 


functional  areas  of  the  hospital  is  to  extract  data  available  from  the  different  MIS  and 
prepared  reports,  manipulate  the  data  into  a  useable  form,  and  present  the  data  to  decision 
makers  for  analysis.  When  faced  with  decision  problems,  resource  managers  analyze  these 
reports  and  MIS  output  for  needed  information.  This  section  provides  a  description  of  the 
different  MIS  at  SBHACH  which  currently  provide  data  to  decision  makers. 

a.  Automated  Quality  of  Care  Evaluation  Support  System  (AQCESS) 
Management  Information  System 

The  AQCESS  MIS  is  a  relatively  recent  addition  to  the  hospital,  having 
just  been  implemented  at  the  first  of  the  year  (1988).  “Bugs”  are  still  being  worked  out, 
but  it  is  still  useful.  The  AQCESS  system  runs  on  a  DEC  1184  computer  and  provides 
information  to  all  clinics  about  patients  and  health-care  providers.  Each  clinic  is  provided 
with  a  separate  terminal  accessing  the  DEC  1184  mainframe.  The  system  provides  quanti¬ 
tative  information  about  the  health-care  services  provided  by  health-care  providers  and  the 
inpatients  receiving  these  services  at  SBHACH. 
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The  AQCESS  system  has  three  modules:  appointment  scheduling, 
quality  assurance,  and  patient  data.  The  appointment  scheduling  module  is  a  decentral¬ 
ized  appointment  scheduling  system  that  is  slowly  replacing  the  existing  centralized 
appointment  scheduling  system  in  the  hospital.  The  appointment  scheduling  module  allows 
the  clinics  to  schedule  their  own  appointments,  schedule  appointment  referrals  to  other 
clinics,  record  appointments  kept,  record  walk-ins,  and  provide  printouts  to  clinics  on 
future  and  past  schedules.  This  module  offers  a  number  of  views  of  data  and  may  be 
broken  down  by  patient,  clinic,  or  health-care  provider  over  varied  time  periods.  Statistical 
information  is  provided  by  this  module  which  is  helpful  in  determining  clinic  and  health¬ 
care  provider  workload  levels. 

The  quality  assurance  module  is  used  to  provide  profile,  monitoring,  and 
general  quality  assurance  repons.  The  profile  reports  give  specific  information  on  health¬ 
care  providers.  The  information  provided  includes  education  history,  personal  and  profes¬ 
sional  credentials,  and  credential  renewal  lists.  Also  provided  are  historical  listings  of  spe¬ 
cific  patients  and  medical  cases  the  health-care  provider  has  treated. 

Monitoring  reports  are  provided  on  both  clinic  and  health-care  providers. 
A  general  list  of  the  types  of  health  care  provided,  such  as  surgery,  physical  therapy,  etc., 
is  provided  by  clinic  and  identifies  patients  treated.  Another  important  monitoring  tool 
identifies  by  patient  name  if  a  specific  health-care  provider  is  delinquent  in  updating  medical 
records.  The  last  reports  provided  by  the  quality  assurance  module  are  general  quality 
assurance  reports.  These  reports  summarize  important  data  such  as  blood  use,  patient 
deaths,  and  readmission  of  patients. 

The  third  AQCESS  module  is  the  patient  data  module.  This  module  pro¬ 
vides  a  comprehensive  record  of  inpatient  data  throughout  the  hospital  wards.  The  data  is  a 


conglomeration  of  necessary  information  about  inpatients  and  is  used  by  the  Patient 
Administration  Division. 

The  AQCESS  system  provides  both  routine  and  ad  hoc  reports.  Some 
reports  are  provided  every  24-hour  period;  specifically,  the  clinic  schedules  for  the  next  day 
are  routinely  routed  to  all  clinics.  A  smaller  number  of  reports  are  requested  on  an  ad  hoc 
basis  whenever  specific  information  is  required  by  resource  managers  [Appendix  D]. 

b.  Uniform  Chart  of  Accounts  Performance  Expense  Reports  System 

(UCAPERS)  Management  Information  System 

The  purpose  of  the  UCAPERS  system  is  to  collect  and  report  on  two 
Uniform  Chart  of  Accounts  data  elements.  The  Uniform  Chart  of  Accounts  is  a  uniform 
accounting  procedure  established  in  1979.  This  procedure  makes  all  military  hospital 
commands  report  on  three  types  of  accounting  data  in  a  consistent  and  uniform  manner. 
The  three  types  of  data  reported  quarterly  to  higher  commands  are  expenses,  personnel 
usage,  and  workload  statistics.  The  UCAPERS  system  reports  personnel  expense  and 
usage  data. 

The  system  records  work  performed  by  civilian  and  military  health-care 
providers,  stores  this  data,  and  submits  it  to  Health  Services  Command  (HSC)  in  a  form  so 
HSC  can  provide  reimbursement  of  funds  to  SBHACH  for  health-care  services  provided. 

The  system  runs  on  Datapoint  hardware  connected  on  an  Attached 
Resource  Computer  (ARC)  network  of  microcomputers  throughout  the  hospital.  The 
importance  of  this  MIS  is  that  it  is  the  basis  for  which  output  in  the  form  of  health-care  ser¬ 
vices  provided  is  related  to  input  in  the  form  of  budgetary  allocation  [Appendix  D]. 
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c.  Standard  Installation  Divisional  Personnel  System  (SIDPERS) 

Management  Information  System 

The  SIDPERS  MIS  is  a  personnel  information  system  keeping  records  on 
all  assigned  military  personnel  at  the  hospital.  It  is  a  personal  computer  system  made  by 
Burroughs  Corporation  that  is  deployable  to  remote  sites. 

SIDPERS  maintains  records  of  military  personnel  assigned  to  SBHACH 
on  a  hard  disk  internal  to  the  computer.  The  data  fields  contain  standard  data  on  each  sol¬ 
dier  as  well  as  detailed  information  on  education,  training,  sex,  religion,  next  of  kin,  etc., 
that  is  necessary  to  the  smooth  functioning  of  military  organizations.  As  information  on  a 
soldier  changes,  or  personnel  are  deleted  or  transferred,  the  database  is  updated  to  reflect 
the  correct  information. 

Each  working  Jay,  the  changes  occurring  over  the  past  day  are  copied 
onto  a  floppy  disk  and  hand-carried  to  the  SIDPERS  on  post  at  Fort  Ord  that  maintains  the 
database  post-wide.  SIDPERS  software  allows  users  to  view  the  database  in  different 
ways.  It  possesses  the  capabilities  of  a  relational  database  that  is  menu  driven  to  provide 
quick  access  to  data  that  satisfies  some  ad  hoc  queries.  In  addition  to  this  function, 
SIDPERS  also  provides  word-processing  capabilities  [Appendix  D], 

4.  Application  of  Resource  Management  DSS 

The  Resource  Management  DSS  will  be  used  to  help  upper-level  managers  deal 
with  ill-structured  problems  in  a  manner  better  than  the  present  resource  management 
method.  The  Resource  Management  DSS  will  go  a  step  beyond  the  MIS  level  of  decision 
support  described  in  Chapter  II  and  will  support  specific  managers  in  the  hospital  chain  of 
command.  The  use  of  the  MIS  to  support  the  Resource  Management  DSS  is  discussed  as 
well  as  managerial  positions  using  the  Resource  Management  DSS. 
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a.  Use  of  MIS  to  Support  Resource  Management  DSS 


As  described  in  Chapter  n,  there  is  a  separation  of  information  gathering 
and  decision  making  that  occurs  with  the  use  of  MIS  and  DSS  technologies.  The  informa¬ 
tion  system  is  used  to  store  and  collect  data.  The  decision-making  system  is  the  actual 
resource  manager  or  managers  tasked  with  analyzing  the  collected  data,  making  predictions 
and  drawing  inferences  from  the  data,  assigning  values  from  inferences  drawn,  and  taking 
action  [Mason  81]. 

MIS  and  DSS  technologies  separate  the  information-gathering  and 
decision-making  systems  in  different  manners.  Figure  3-2(a)  [Mason  81]  represents 
support  an  MIS  lends  to  the  decision  process.  The  information  system  is  tasked  with 
storing,  retrieving,  and  classifying  potentially  useful  data  for  the  decision-making  system. 
The  decision-making  system  then  determines  from  which  areas  the  data  must  be  retrieved 
and  makes  these  requests  to  the  information  system.  Mason  points  out  that  it  is  not  feasible 
for  the  information  system  to  have  the  capability  of  retrieving  all  combinations  and 
permutations  of  possible  requests.  Therefore,  the  decision  system  is  tasked  with  gener¬ 
ating  these  requests,  drawing  inferences  and  predictions  from  delivered  rt  orts,  assigning 
values,  and  choosing  a  course  of  action.  Resource  managers  at  SBHACH  request  data 
from  the  different  MIS  within  the  hospital  to  address  specific  problems.  Data  is  then 
analyzed  and  a  course  of  action  is  chosen. 

The  Resource  Management  DSS  for  SBHACH  will  go  a  step  beyond  the 
MIS  level  and  provide  predictive  information  to  decision  makers.  Figure  3-2(b)  combines 
the  ability  to  make  predictions  and  draw  inferences  from  the  data.  In  this  manner,  the  deci¬ 
sion-making  system  (people)  can  ask  “What  if?”  questions  and  get  appropriate,  timely 
responses  from  the  information  system.  The  people  then  assign  values  to  possible  choices 
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(b)  DSS  Support  of  Decision  Process 
Figure  3-2.  MIS  and  DSS  Support  of  Decision  Process 

and  take  action.  The  Resource  Management  DSS  is  designed  to  allow  resource  managers 
to  readily  access  databases  created  by  the  DSS  consisting  of  extracted  data  from  the 
AQCESS,  UCAPERS,  and  SIDPERS  MIS.  Resource  managers  can  ask  “What  if?”  ques¬ 
tions  and  project  future  trends  based  on  historical  data.  From  these  responses  to  queries  of 
the  information  system,  the  decision-making  system  can  take  action  on  values  assigned  to 
the  different  possible  choices  and  choose  a  course  of  action. 

Chapter  II  also  presented  a  DSS  acting  as  an  intermediary  between  the 
user  and  MIS.  Figure  3-3  [Sprague  82]  shows  the  data-extraction  system  taking  needed 
data  from  the  UCAPERS,  SIDPERS,  and  AQCESS  MIS  and  creating  databases  for  use  by 
the  DSS.  Some  of  the  databases  created  will  be  used  for  providing  routine  information, 
while  other  databases  will  be  temporarily  created  and  discarded  after  use.  Chapter  IV 
describes  the  databases  to  be  created  to  support  the  the  Resource  Management  DSS. 


Figure  3-3.  DSS  Sub-Components  With  Data  Extraction  System 

b.  Managers  Supported  by  Resource  Management  DSS 

The  Resource  Management  DSS  will  support  primarily  managers  in  the 
Resource  Management  Division  and  the  Clinical  Support  Division.  The  Resource  Man¬ 
agement  Division  is  responsible  for  providing  a  variety  of  services  pertaining  to  the  pro¬ 
gramming,  budgeting,  accounting,  review,  and  analysis  of  overall  resource  usage.  The 
Clinical  Support  Division  is  responsible  for  providing  centralized  administrative  manage¬ 
ment  support  to  all  professional  elements  of  the  hospital  [Army  Reg  40-3  85]. 

The  Clinical  Support  and  Resource  Management  Divisions  report  directly 
to  the  Deputy  Commander  for  Clinical  Services  and  Deputy  Commander  for  Administra¬ 
tion,  respectively  (see  Figure  3-4).  The  importance  of  emphasizing  this  relationship  is 
clear.  The  two  divisions  using  the  DSS  can  act  as  facilitators  to  their  respective  deputy 
commanders,  who  in  turn  advise  the  Hospital  Commander.  Managers  in  these  divisions 
can  operate  the  Resource  Management  DSS  and  provide  answers  to  ad  hoc  requests  as  well 
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as  routine  queries.  Figure  3-4  also  served  as  a  starting  point  when  initially  identifying 
resource  managers  that  would  provide  information  from  which  CSFs  could  be  determined. 


Figure  3-4.  Managers  Supported  by  DSS 


B .  METHODOLOGY  OF  CSF  STUDY 

Although  CSFs  were  introduced  in  Chapter  I,  a  more  in-depth  discussion  of  CSFs  is 

needed.  This  section  also  discusses  the  methods  used  to  collect  data  to  determine  hospital 

CSFs  and  the  way  CSFs  are  derived  from  collected  data. 

As  a  review,  Bullen  and  Rockart  describe  CSFs  as: 

the  limited  number  of  areas  in  which  satisfactory  results  will  ensure  successful  com¬ 
petitive  performance  for  the  individual,  department  or  organization.  CSFs  are  those 
key  areas  where  “things  must  go  right”  for  the  business  to  flourish  and  for  the  man¬ 
ager’s  goals  to  be  attained.  [Bullen  81] 
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The  most  difficult  part  of  analyzing  management  information  needs  is  eliciting  what 
“key  areas”  of  business  activity  are  necessary  to  reach  established  goals  [Rockart  82]. 
CSFs  give  insight  into  the  organization  and  aid  in  planning  and  developing  information 
systems  to  support  data  requirements  needed  to  monitor  organizational  CSFs. 

A  review  of  the  literature  on  CSFs  identified  seven  primary  sources  of  CSFs  [Bullen 
81].  Table  3-1  lists  these  seven  CSF  sources,  describes  each  source,  and  provides  an 
example  relevant  to  the  health-care  industry.  Bullen  and  Rockart  stress  that  each  source 
should  be  investigated  thoroughly  in  order  to  elicit  all  CSFs  pertaining  to  an  organization. 

1.  Method  of  Data  Collection 

Bullen  and  Rockart  describe  the  use  of  structured  interviews  to  identify  “key 
areas”  that  managers  need  to  monitor  in  order  to  be  successful  [Bullen  81].  Structured 
interviews  of  key  resource  managers  throughout  the  hospital  chain  of  command  were  used. 
Interviews  conducted  identified  key  areas  important  to  SBHACH  managers  and  discovered 
the  information  needs  currently  used  or  desired  by  administrators  in  order  to  satisfy  these 
needs.  Interviews  of  personnel  tasked  with  operating  the  various  MIS  were  also  conducted 
as  well  as  data  collection  in  the  form  of  participant  observation. 
a.  Upper  Level  Management  Interviews 

The  author  conducted  a  series  of  structured  interviews  with  upper-level 
managers  at  the  hospital.  A  preliminary  interview  and  six  CSF  interviews  were  conducted 
to  collect  data  on  the  information  requirements  necessary  to  properly  manage  hospital 
resources. 

One  hour-long  interview  was  conducted  in  order  to  identify  preliminary 
problem  areas  and  determine  whether  a  DSS  could  aid  in  solving  these  problem  areas.  The 
Chief  of  Resource  Management  Division  and  the  Chief  of  Clinical  Support  Division  were 
interviewed. 


Six  hour-long  structured  interviews  were  next  conducted  to  identify  spe¬ 
cific  CSFs.  A  structured  interview  questionnaire  developed  as  part  of  the  thesis  (Appendix 
B)  was  used  to  elicit  the  different  CSFs  by  focusing  on  CSF  primary  sources  identified  in 
Table  3-1.  The  following  personnel  were  interviewed  in  the  order  listed: 

•  Nursing  Methods  Analyst 

•  Chief  of  Patient  Administration  Division 

•  Chief  of  Personnel  Division 

•  Deputy  Commander  for  Administration 

•  Deputy  Commander  for  Clinical  Services 

•  Commanding  Officer,  SBHACH 

The  top-down  approach  is  a  method  described  by  Bullen  and  Rockart  to 
move  from  an  individual  manager’s  focus  on  business  objectives  to  an  information  systems 
focus.  In  the  course  of  the  interview,  the  manager  is  encouraged  to  discuss  his  business 
environment,  consisting  of  his  strategies,  goals,  and  objectives  [Bullen  81].  Figure  3-5 
[Bullen  81]  demonstrates  that  as  the  manager  identifies  the  goals,  strategies,  and  objectives 
that  he  holds  within  his  sub-organizational  element,  he  invariably  identifies  reports  and 
sources  of  data  that  satisfy  his  information  needs.  From  these  reports  and  data  sources, 
analysts  are  able  to  design  databases  and  information  systems  that  will  provide  managers 
with  needed  information  to  make  decisions  supporting  his  goals,  strategies,  and  objectives. 

Bullen  and  Rockart  also  suggest  that  structured  interviews  start  at  the 
lowest  level  possible  in  the  organizational  level  and  work  upward  [Bullen  81].  After  the 
researcher  became  familiar  with  the  organizational  structure  and  current  information  man¬ 
agement  practices,  structured  interviews  were  conducted  by  starting  at  the  lower  levels  and 
progressing  upward.  By  starting  at  the  lower  levels,  important  knowledge  was  gained  in 
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tablem 


PRIMARY  SOURCES  OF  CRITICAL  SUCCESS  FACTORS 

[based  on  Bullen  81] 


Primary  Source 

Description 

Example 

1.  Industry 

Factors  determined  by 
the  industry  itself 

Quality  of  health  care 
to  patients 

2.  Competitive 
Strategy  and 
Industry  Position 

Industry  position  in 
which  the  organization 
finds  itself 

Surrounding  communities’ 
expectation  of  health¬ 
care  services 

3.  Environmental 

Areas  over  which  the 
organization  has  very 
litde  or  no  control 

Fluctuation  of  patient 
levels 

4.  Temporal 

Areas  that  become 
temporarily  important 
for  a  period  of  time 

AIDS  concern 

5.  Managerial 

Position 

The  different  factors 
that  are  important  to 
different  managers 
with  the  organization 

Accuracy  and  timeliness 
of  lab  results  to  the 
individual  clinics 

6.  Internal  and 
External 

Factors  that  are  inside 
an  individual  manager’s 
sphere  of  influence  or 
external  to  a  manager’s 
control 

Clinic  staffing  levels 
are  not  controllable 
by  individual  clinic 
chiefs,  but  are  control¬ 
lable  by  the  hospital 
commander 

7 .  Monitoring  and 
Building 

A  difference  in  classi¬ 
fication  of  whether  a 
manager  is  more  con¬ 
cerned  with  tracking  the 
organization’s  progress 
(monitoring)  or  planning 
the  next  move  (building) 

Monitoring — tracking 
seriously  ill  patients 

B  uilding — analyzing 
plans  to  open  a  new 
inpatient  ward 
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Figure  3-5.  Manager’s  Business  Environment  and  Focus: 
Strategies  to  Information  Systems 


order  to  become  more  comfortable  in  conducting  interviews  further  up  the  hospital  chain  of 
command.  Reports  and  databases  were  identified  in  the  lower  levels  and  the  interviewer 
became  more  knowledgeable  in  the  organizational  workings  and  identified  where  data 
originates  and  how  it  is  processed  before  finally  getting  to  upper-level  decision  makers.  As 
CSFs  were  discovered,  it  was  found  that  the  lower-level  managers  were  an  important 
source  of  identifying  where  data  was  extracted  from  and  that  higher-level  managers  were 
beneficial  in  prioritizing  CSFs. 
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b.  Information  Management  Personnel  Interviews 

Three  hour-long  interviews  were  conducted  with  information  management 
personnel  responsible  for  the  maintenance  and  upkeep  of  the  many  MIS  in  operation  at 
SBHACH.  The  purpose  of  these  interviews  was  to  provide  a  description  of  the  different 
MIS  that  maintain  relevant  data  used  by  resource  managers. 

c.  Participant  Observation 

The  final  method  of  data  collection  was  participant  observation.  This 
data-collection  method  consisted  of  observing  several  information  management  meetings 
conducted  by  managers  and  by  analyzing  reports  and  databases  throughout  the  hospital. 
The  information  management  meetings  provided  a  focus  from  which  trends  and  directions 
of  the  development  of  organizational  information  technology  could  be  studied. 

2.  Derivation  of  CSFs 

Bullen  and  Rockart  provide  a  methodology  for  deriving  an  organization’s  CSFs 
from  the  data  collected  during  structured  interviews.  The  key  to  successfully  determining 
organizational  CSFs  is  in  determining  the  individual  manager’s  CSFs.  Each  manager  is 
interviewed,  concentrating  on  the  seven  primary  source  of  CSFs  listed  in  Table  3-1  [Bullen 
81].  The  emphasis  is  to  ensure  that  all  potential  sources  of  CSFs  are  discussed  to  “leave  no 
stone  unturned.”  The  manager’s  CSFs  are  then  listed  and  prioritized. 

The  next  step  described  by  Bullen  and  Rockart  is  the  aggregation  of  individual 
managers’  CSFs.  The  researcher  takes  each  manager’s  CSFs  and  combines  all  CSFs  into 
an  organizational  view.  This  aggregation  is  conducted  with  the  focus  on  extracting  the 
organization’s  CSFs  and  prioritizing  them  [Bullen  81].  The  next  section  will  discuss  the 
data  collected  and  the  organizational  CSFs  derived  from  the  data. 
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C.  CRITICAL  SUCCESS  FACTOR  FINDINGS 

The  previous  section  discussed  the  methodology  of  the  CSF  research,  describing 
how  CSF  data  were  elicited  from  upper-level  managers  and  how  an  organization’s  CSFs 
are  derived  from  individual  manager  CSFs.  This  section  identifies  the  appendices  summa¬ 
rizing  the  data  discovered  during  structured  interviews  and  presents  the  SBHACH  CSFs. 

1.  CSF  Data 

The  interviews  conducted  at  SBHACH  are  summarized  in  Appendices  A,  C, 
and  D.  The  positions  of  resource  managers  are  identified,  but  the  names  of  personnel 
interviewed  were  not  included  even  though  nothing  inappropriate  was  discussed  during 
interviews.  These  appendices  served  as  documentation  for  the  development  of  the 
SBHACH  CSFs. 

The  structured  interviews  conducted  with  upper-level  managers  are  presented  in 
a  partitioned  format.  The  interviews  are  separated  by  each  individual  manager  and  pre¬ 
sented  in  the  order  in  which  they  occurred.  Each  interview  is  divided  into  the  seven 
primary  sources  of  CSFs,  as  shown  in  Table  3-1.  Data  discovered  was  placed  into  one  of 
the  primary  CSF  sources.  Summaries  of  the  six  upper-level  management  interviews  con¬ 
ducted  at  SBHACH  are  found  in  Appendix  C. 

The  interviews  conducted  with  management  information  personnel  are  summa¬ 
rized  by  the  type  of  MIS  that  the  particular  individual  was  responsible  for  maintaining.  All 
detailed  information  about  existing  MIS  at  SBHACH  was  discussed  during  these  inter¬ 
views,  which  are  summarized  in  Appendix  D. 

2.  Presentation  of  CSFs 

An  analysis  of  the  data  collected  during  CSF  interviews  indicated  that 
SBHACH  had  four  CSFs.  These  four  organizational  CSFs  are  the  major  concerns  on 
which  upper-level  managers  at  SBHACH  must  focus  their  attention.  The  four  CSFs  are 
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presented  in  this  section,  along  with  proposed  measures  the  Resource  Management  DSS 
should  be  able  to  provide  in  order  to  satisfy  information  needs.  Also  discussed  are  project 
requirements  that  are  of  an  information  systems  focus  which  the  Resource  Management 
DSS  should  also  provide. 

a.  Critical  Success  Factor  1:  Maintain  Sufficient  Fiscal  Resources  to 

Meet  the  Demands  For  Inpatient  and  Outpatient  Health-Care 

Services 

Medical  Treatment  Facilities  (MTFs)  were  established  to  provide  medical 
care  to  authorized  DOD  personnel  and  their  dependents.  Although  these  MTFs  are  non¬ 
profit  oriented,  they  still  must  somehow  account  for  the  large  expenditures  of  funding  pro¬ 
vided  by  DOD.  Health  Services  Command  (HSC)  must  monitor  these  MTFs  and  provide 
funding  in  relation  to  some  quantifiable  measurement  of  services  rendered  by  the  individual 
hospitals. 

The  current  trend  is  for  MTFs  to  be  reimbursed  relative  to  the  health-care 
services  that  they  provide  [Appendix  A].  HSC  closely  monitors  each  hospital,  measures 
their  expenditures  in  health-care  services  rendered,  and  reimburses  them  in  relation  to  this 
expenditure. 

The  current  system  of  reporting  to  DOD  the  amount  of  health-care  services 
provided  by  the  MTF  is  based  on  a  unit  called  a  Medical  Care  Composite  Unit  (MCCU). 
When  health-care  providers  (doctors,  nurses,  lab  technicians,...)  provide  services  to 
patients  in  the  form  of  consults,  surgery,  pharmaceutical  prescriptions,  bed  space,  radiol¬ 
ogy,  and  other  varied  services,  the  MTF  is  credited  with  MCCUs  depending  on  the  type  of 
service.  For  example,  an  outpatient  visit  is  worth  roughly  0.3  MCCUs,  a  live  birth  is  val¬ 
ued  at  10  MCCUs,  and  admission  as  an  inpatient  is  worth  10  MCCUs  the  first  day  and  1 
MCCU  every  day  thereafter.  All  health-care  services  provided  are  input  daily  by  data  entry 
clerks  and  maintained  on  a  MIS.  The  information  is  updated  daily,  and  weekly  a  tape  is 
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run  summarizing  all  health-care  services  provided  by  the  MTF  for  the  past  seven-day 
period.  A  copy  of  the  tape  is  sent  to  a  DOD-run  facility  where  the  data  is  calculated  into 
MCCUs.  These  MCCUs  are  used  by  DOD  quarterly  to  provide  monetary  funding  to 
SBHACH  in  reimbursement  for  health-care  services  provided  at  the  MTF.  A  hard-copy 
report  is  forwarded  to  the  MTF  one  month  after  the  quarter  has  expired  summarizing  the 
MCCUs  earned  for  the  previous  quarter  [Appendix  C]. 

The  proposed  measures  of  the  Resource  Management  DSS  for  satisfying 
this  CSF  should  maintain  a  productivity  database  that  accurately  provides  performance  and 
productivity  criteria  to  resource  managers  that  will  do  the  following: 

•  Compare  current  clinic  work  unit  levels  to  historic  values. 

•  Forecast  future  clinical  productivity  using  historic  data  and  user-projected  values. 

•  Forecast  future  hospital  productivity  using  historic  data  and  user-projected  values. 

•  Compare  current  MCCU  data  to  historical  data  and  projected  goals. 

•  Project  future  MCCU  values  based  on  current  trends  of  MCCU  earnings  and  user- 
projected  values. 

•  Calculate  unused  capacity  in  the  form  of  bed  space  and  potential  discharge 
information. 

•  Calculate  projected  bed  space  required  based  on  current  trends. 

The  system  should  also  provide  functions  that  are  of  an  information  sys¬ 
tems  focus  along  with  the  DSS  provided  measures.  The  Resource  Management  DSS 
should  also  do  the  following: 

•  Calculate  monthly  work  units  accomplished  by  individual  clinics. 

•  Calculate  the  number  of  MCCUs  earned  by  the  hospital  to  date. 

•  Graph  and  chan  work  units  accomplished  over  time  for  presentation  to  decision 
makers. 

•  Calculate  the  entire  hospital’s  earned  MCCUs  each  day  to  an  acceptable  degree  of 
accuracy,  and  compare  the  moving  average  to  projected  goals. 


54 


b.  Critical  Success  Factor  2:  Maintain  Sufficient  Military  and  Civil¬ 
ian  Personnel  to  Adequately  Provide  Health-Care  Services  to 
Fluctuating  Inpatient  and  Outpatient  Levels 

This  CSF  deals  with  properly  staffing  wards  and  clinics  to  meet  the  fluc¬ 
tuating  demand  of  inpatients  and  outpatients.  By  providing  an  adequate  number  of  health¬ 
care  providers  at  varying  levels  of  demand,  the  hospital  will  provide  an  acceptable  level  of 
medical  care  to  all  personnel  authorized  medical  care  at  SBHACH.  At  present,  civilian  and 
military  levels  are  tracked  by  the  Personnel  Division.  When  fluctuating  patient  levels  and 
operational  commitments  overburden  the  staffing  levels  of  wards  and  clinics,  decisions 
must  be  made  to  reallocate  health-care  providers.  Decisions  must  also  be  made  when  hiring 
civilians  to  replace  vacant  positions  within  the  hospital  [Appendix  CJ. 

The  proposed  measures  for  the  Resource  Management  DSS  satisfying  this 
CSF  are  to  maintain  a  manpower  database  to  include  all  officer,  enlisted,  and  civilian  per¬ 
sonnel  assigned  to  the  hospital  that  will  do  the  following: 

•  Project  gains/losses  for  six  months  in  the  future  for  military  and  civilian  personnel. 

•  Forecast  clinical  staffing  levels  from  historical  data  and  user-projected  input 

•  Compare  different  clinical  productivity  levels  at  the  same  time. 

The  system  should  also  provide  functions  that  are  of  an  information  sys¬ 
tems  focus  along  with  the  DSS  provided  measures.  The  Resource  Management  DSS 
should  also  do  the  following: 

•  Compare  onboard  count  to  authorized  billets  hospital  wide  as  well  as  at  the  clinic 
level. 

•  Maintain  required  qualification  records  on  military  health-care  providers  assigned  to 
deployable  forces. 
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c.  Critical  Success  Factor  3:  Monitor  the  Impact  of  the  Primary  Care 
to  Uniformed  Services  (PRIMUS)  Clinics  and  the  Civilian  Health 
And  Medical  Program  of  the  Uniformed  Services  (CHAMPUS) 
Reform  Initiative 

The  two  PRIMUS  clinics  being  opened  at  The  Presidio  of  Monterey  and 
Salinas,  California,  are  designed  to  provide  health-care  services  to  active  duty,  retired,  and 
dependent  personnel  as  an  alternative  to  the  medical  treatment  also  provided  at  SBHACH. 
The  medical  care  is  provided  mostly  by  civilian  personnel  under  contract  and  covers  small 
injuries,  common  illnesses,  and  general  medical  problems.  Although  the  two  PRIMUS 
clinics  will  duplicate  a  percentage  of  medical  care  that  is  already  provided  at  SBHACH, 
there  are  certain  medical  services  not  rendered. 

SBHACH  will  still  offer  all  medical  services,  but  the  PRIMUS  clinics  will 
take  some  of  the  workload  from  the  hospital  and  give  additional  medical  care  to  the  sur¬ 
rounding  military  community.  The  PRIMUS  clinics  can  have  three  effects  on  the  hospital: 
they  may  “steal  patients  away”  from  the  hospital  and  cause  the  overall  hospital  productivity 
to  drop;  they  may  increase  the  amount  of  patients  treated  through  patient  referrals;  or  the 
patient  levels  will  remain  the  same. 

The  CHAMPUS  reform  initiative  is  a  program  sponsored  by  HSC  to 
retard  the  yearly  costs  of  CHAMPUS,  which  currently  are  rising  at  a  rate  of  25  percent  per 
year.  In  effect,  the  purpose  of  the  CHAMPUS  reform  initiative  is  to  identify  a  number  of 
health-care  providers  outside  the  military  hospital  system  who  can  provide  medical  care  for 
the  overflow  of  patients  at  SBHACH  less  expensively  than  their  contemporaries.  These 
health-care  providers  under  contract  will  cost  the  government  less  in  CHAMPUS  costs  then 
the  current  method  of  using  more  expensive  outside  medical  practitioners  [Appendix  Cj. 

The  proposed  measures  for  the  Resource  Management  DSS  satisfying  this 
CSF  are  to  maintain  a  database  that  contains  the  fluctuation  of  inpatient  and  outpatient 
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treatment  during  the  opening  of  the  PRIMUS  clinics  and  the  start-up  of  the  CHAMPUS 
reform  initiative  that  should  do  the  following: 

•  Measure  the  daily  fluctuation  of  clinic  productivity  in  work  units  compared  to  histori¬ 
cal  values. 

•  Forecast  the  number  of  outpatients  in  the  future  based  on  historical  referrals  from  the 
PRIMUS  clinics. 

•  Measure  the  daily  fluctuation  of  clinic  MCCUs  earned  compared  to  historical  values. 

•  Project  trends  of  outpatient  drops  due  to  loss  of  outpatients  to  PRIMUS. 

The  system  should  also  provide  functions  that  are  of  an  information  sys¬ 
tems  focus  along  with  the  DSS-provided  measures.  The  Resource  Management  DSS 
should  also  do  the  following: 

•  Monitor  the  number  of  patients  treated  due  to  referrals  from  the  PRIMUS  clinics. 

•  Calculate  the  daily  loss  of  MCCUs  due  to  drops  in  outpatient  levels. 

d.  Critical  Success  Factor  4:  Maintain  a  Sufficient  Amount  of  Medical 

Equipment  in  Proper  Working  Order  to  Provide  Necessary  Health- 

Care  Services  to  Inpatient  and  Outpatient  Demands 

SBHACH  makes  significant  budget  expenditures  on  capital  equipment 
each  fiscal  year.  There  are  varying  life  cycles  of  different  types  of  equipment,  and  occa¬ 
sionally  the  equipment  does  not  last  the  entire  life  cycle  and  must  be  budgeted  for  earlier 
than  expected.  An  important  information  requirement  is  to  accurately  project  future 
requirements  of  equipment  which  will  have  to  be  planned  for  in  the  yearly  budget 
[Appendix  C]. 

The  proposed  measures  for  the  Resource  Management  DSS  satisfying  this 
CSF  are  to  maintain  a  database  that  tracks  major  items  and  contains  records  on  cost,  serial 
numbers  issued,  acquisition  date,  expected  life  cycle,  anticipated  expiration  date,  and  other 
pertinent  information.  The  proposed  measure  should  do  the  following: 


•  Forecast  future  monthly  budget  expenditures  on  capital  equipment  based  on  historical 
data. 

•  Forecast  future  monthly  budget  expenditures  on  capital  equipment  based  on  projected 
user  input. 

The  system  should  also  provide  functions  that  are  of  an  information  sys¬ 
tems  focus  along  with  the  DSS-provided  measures.  The  Resource  Management  DSS 
should  also  do  the  following: 

•  Calculate  total  cost  of  the  yearly  budget  portion  allocated  for  the  purchase  of  capital 
equipment. 

•  Break  down  the  equipment  by  functional  wards  and  clinics  and  provide  varied  views 
of  the  database. 

•  Identify  equipment  approaching  the  end  of  its  useful  life  cycle. 

D.  SUMMARY 

This  chapter  discussed  the  derivation  of  SBHACH  CSFs  in  preparation  for  the  design 
phase  of  the  Resource  Management  DSS  presented  in  the  next  chapter.  This  chapter  also 
discussed  the  organizational  setting  of  SBHACH,  the  methodology  of  collecting  data  for 
analysis,  and,  most  importantly,  presented  the  four  CSFs  derived  from  collected  data. 

In  discussing  the  organizational  setting,  the  current  method  of  resource  management 
used  by  hospital  administrators  was  presented.  The  three  MIS  used  for  data  sources  were 
presented  in  detail  because  these  same  MIS  will  be  used  by  the  Resource  Management  DSS 
to  extract  relevant  data  from.  Finally,  the  actual  managerial  positions  in  the  hospital  chain 
of  command  which  will  use  the  Resource  Management  DSS  were  identified. 

The  next  section  of  this  chapter  discussed  the  methodology  used  to  collect  data.  The 
three  methods  of  data  collection — upper-level  management  interviews,  information  man¬ 
agement  personnel  interviews,  and  participant  observation — were  presented.  The  person¬ 
nel  interviewed  were  identified  by  their  position  within  the  organization.  The  importance  of 
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the  interviews  is  stressed  because  the  CSFs  for  SBHACH  were  derived  from  this  collected 
data. 

Finally,  the  organizational  CSFs  for  SBHACH  were  presented  in  detail  with  the  pro¬ 
posed  measures  which  were  developed  to  satisfy  the  information  requirements  of  each 
CSF.  Table  3-2  summarizes  the  four  organizational  CSFs  derived  from  collected  data. 
The  next  chapter  will  take  a  portion  of  these  derived  CSFs  and  design  the  first  iteration  of 
the  Resource  Management  DSS. 


TABLE  3-2 

SBHACH  PRIORITIZED  CRITICAL  SUCCESS  FACTORS  (CSFs) 


Priority  Critical  Success  Factor 

1  st  Maintain  sufficient  fiscal  resources  to  meet  the  demands 

for  inpatient  and  outpatient  health-care  services. 

2nd  Maintain  sufficient  military  and  civilian  personnel  to 

adequately  provide  health-care  services  to  fluctuating 
inpatient  and  outpatient  levels. 

3rd  Monitor  the  impact  of  the  Primary  Care  to  Uniformed 

Services  (PRIMUS)  and  the  Civilian  Health  and  Medical 
Program  of  the  Uniformed  Services  (CHAMPUS) 
reform  initiative. 

4th  Maintain  a  sufficient  amount  of  medical  equipment  in 

proper  working  order  to  provide  necessary  health-care 
services  to  inpatient  and  outpatient  demands. 
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IV.  DESIGN  OF  DECISION  SUPPORT  SYSTEM  (DSS) 


Chapter  in  discussed  the  analysis  phase  of  the  Resource  Management  Decision  Sup¬ 
port  System  (DSS)  at  Silas  B.  Hays  Army  Community  Hospital  (SBHACH)  in  order  to 
identify  critical  information  requirements  needed  by  resource  managers.  Chapter  IV  takes 
information  found  during  the  analysis  phase  and,  using  structured  design  tools,  provides 
necessary  documentation  from  which  the  first  iteration  of  the  Resource  Management  DSS 
can  be  implemented. 

As  described  in  Chapter  II,  a  small  sub-problem  of  the  DSS  is  agreed  upon  between 
user  and  builder.  The  builder  designs  a  system  and  presents  it  to  the  user  for  feedback. 
The  builder  makes  necessary  corrections  and  repeats  the  process  by  building  on  the  existing 
system  [Sprague  86].  This  first  iteration  of  the  Resource  Management  DSS  will  be  pre¬ 
sented  to  users  for  review  and  will  serve  as  the  system’s  cornerstone  from  which  the  full- 
scale  Resource  Management  DSS  can  be  constructed. 

In  order  to  design  the  first  iteration,  a  partition  of  the  DSS  analysis  is  made  and  the 
design  of  a  sub-problem  is  conducted.  This  chapter  discusses  a  portion  of  the  Critical 
Success  Factor  (CSF)  that  will  be  designed  from  this  partition.  A  transformation  from 
analysis  to  design  using  structured  specification  and  module  specification  tools  is 
described.  In  addition,  this  chapter  also  describes  the  Resource  Management  DSS  con¬ 
struction  using  the  data,  dialog,  and  modeling  components  presented  in  previous  chapters. 
The  delivered  product  from  this  chapter  will  provide  follow-on  researchers  with  sufficient 
documentation  to  implement  the  first  iteration  of  the  SBHACH  Resource  Management  DSS 
in  a  structured  programming  language  such  as  PASCAL. 
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A.  SIZE  OF  FIRST  DSS  ITERATION  (VERSION  0) 

Version  0  of  the  Resource  Management  DSS  is  limited  to  providing  information  and 
modeling  capabilities  to  satisfy  two  of  three  proposed  measures  found  in  the  first  CSF. 
The  first  CSF  is  to  provide  information  to  decision  makers  in  order  to  maintain  sufficient 
fiscal  resources  to  meet  the  demands  for  inpatient  and  outpatient  health-care  services. 

The  two  areas  from  the  first  CSF  to  be  satisfied  are  Medical  Care  Composite  Unit 
(MCCU)  earnings  and  productivity  trends.  A  discussion  of  these  two  areas  will  provide 
the  reader  with  an  understanding  of  the  type  of  information  required  to  satisfy  a  portion  of 
the  first  CSF. 

1.  Medical  Care  Composite  Unit  (MCCU) 

The  Resource  Management  DSS  must  provide  decision  makers  with  daily  and 
monthly  MCCU  earnings.  The  most  recent  30-day  earning  of  MCCUs  can  be  extracted 
and  graphed  to  display  MCCU  earning  trends.  Resource  managers  can  also  monitor  the 
number  of  MCCUs  earned  by  the  hospital  to  date  for  the  current  fiscal  year. 

A  monthly  database  of  the  current  and  previous  years’  MCCU  earnings  will 
allow  the  comparison  of  recent  data  to  the  previous  year’s  data.  From  this  historical 
database,  projections  of  the  next  six  months’  MCCU  earnings  can  be  made  based  on  recent 
trends  using  a  moving  average  calculation  formula.  Also,  users  can  input  predictions  for 
future  months  and  project  up  to  six  months  of  MCCU  earnings  in  the  future.  Graphics  in 
the  form  of  a  spreadsheet  application  will  plot  the  MCCU  earnings  and  save  desired  data  to 
files  for  later  use. 

2.  Productivity 

Productivity  databases  will  provide  information  about  individual  clinics  as  well 
as  hospital-wide  in  the  form  of  work  units  earned  in  comparison  to  health-care  providers 
assigned.  For  both  the  hospital  and  individual  clinics,  the  last  six  months  of  monthly 
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productivity  earnings  can  be  graphed  on  a  spreadsheet  application  and  saved  for  future  use. 
In  addition  to  historical  trends,  productivity  projections  can  be  made  based  on  the  last  few 
months’  earnings  or  based  on  the  user’s  predictions  of  future  months’  productivity. 

B .  TRANSFORMATION  OF  ANALYSIS  TO  DESIGN 

It  is  important  to  correctly  transform  the  analysis  into  a  system  design.  Page- Jones 
describes  this  procedure  as  taking  the  voluminous  amount  of  information  produced  during 
the  analysis  phase  and  determining  how  to  organize  what  it  describes  in  a  manner  suitable 
for  computer  execution  [Page-Jones  80]. 

The  transformation  of  analysis  to  design  is  made  in  two  steps.  In  the  first  step,  the 
structured  specification  primarily  uses  three  tools  to  logically  describe  the  evolving  system. 
The  module  specification  is  the  second  step  and  uses  two  tools  to  describe  procedural 
detail.  The  by-products  of  these  two  design  steps  will  provide  sufficient  documentation 
from  which  source  code  can  be  developed. 

This  section  will  describe  the  structured  specification  and  the  module  specification 
design  steps.  The  tools  used  to  transform  analysis  to  design  will  be  discussed  and  specific 
examples  presented  from  the  Resource  Management  DSS.  Finally,  the  appendices  con¬ 
taining  documentation  from  this  design  phase  will  be  referenced. 

1.  Structured  Specification 

A  structured  specification  is  used  to  allow  the  system  builder  to  clearly  under¬ 
stand  the  workings  of  a  system  and  create  a  design  quickly  and  accurately  showing  what 
the  system  will  do  [Page-Jones  80].  Page-Jones  describes  a  structured  specification  as 
having  the  following  characteristics: 

•  Graphic  and  concise; 

•  Top-down  partitioned; 


•  Non-redundant; 

•  Logical,  not  physical. 

In  other  words,  the  structured  specification  contains  pictures  rather  than  text 
[Page-Jones  80].  Graphical  representations  of  data,  data  flows,  and  processes  are  better 
understood  than  textual  descriptions.  The  structured  specification  breaks  the  system  down 
into  smaller,  independent  pieces  for  easier  understanding.  It  is  also  non-redundant  in  that 
the  structured  specification  records  a  piece  of  information  only  once  for  consistency  and 
accuracy.  Finally,  the  structured  specification  focuses  on  what  the  system  will  accomplish 
for  the  user  (the  logical)  rather  than  on  how  the  system  will  be  implemented  by  a  particular 
machine  [Page-Jones  80]. 

The  structured  specification  primarily  consists  of  the  following  three  tools: 

•  Leveled  Data  Flow  Diagrams  (DFDs); 

•  Tools  to  describe  policy; 

•  Data  dictionary. 

Using  structured  specification  tools  will  enable  designers  to  easily  create  a 
description  of  what  the  system  is  performing.  The  remainder  of  this  section  will  describe 
these  tools. 

a.  Leveled  Data  Flow  Diagrams  (DFDs) 

The  DFD  is  used  to  partition  a  system  and  is  desirable  because  it  is 
graphic,  concise,  and  non-redundant  [Page-Jones  80].  DFDs  consist  of  four  elements: 
data  flows,  processes,  data  stores,  and  sources/sinks.  Figure  4  1(a)  provides  a  sample 
DFD  as  it  appears  with  all  four  elements.  Figure  4- 1(b)  shows  a  portion  of  the  DFD  from 
the  Resource  Management  DSS. 

A  data  flow  consists  of  data  moving  between  processes,  data  stores,  and 
sources/sinks.  The  name  of  the  data  flow  is  written  beside  the  data  flow  and  an  arrow 


Dal  a  Flow  1 


2 

Process 


Data  Flow  6 


1 


(a)  Data  Flow  Diagram  Components 


(b)  Sample  Resource  Management  DSS  Data  Flow  Diagram 
Figure  4-1.  Data  Flow  Diagrams 
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indicates  the  direction  in  which  the  data  are  moving.  According  to  Page-Jones,  the  data 
flow  can  be  thought  of  as  parts  being  delivered  on  a  conveyer  belt  or  a  pipeline  carrying 
pieces  of  data  [Page-Jones  80]. 

A  process  is  used  to  transform  data  in  one  of  two  ways.  A  process  may 
transform  the  structure  of  data  by  reformatting  it  or  may  transform  the  information  con¬ 
tained  in  the  data  [Page-Jones  80].  Note  that  in  Figure  4-  1(a),  data  flows  going  into  a  pro¬ 
cess  do  not  have  the  same  names  as  data  flows  leaving  the  process  because  the  data  was 
somehow  changed.  Figure  4- 1(b)  shows  six  different  data  flows  coming  into  the  process 
CALCULATE  MCCUS  and  a  single  data  flow  leaving  it.  The  six  data  flows  coming  in 
were  used  to  generate  a  single  data  flow  leaving  the  module. 

A  data  store  is  a  temporary  storage  area  for  data  to  be  used  by  the  system. 
In  essence,  data  stores  are  the  created  databases  used  by  the  Resource  Management  DSS 
from  which  to  extract  data.  The  data  store  DAILY  MCCUS  CURRENT  FISCAL  YEAR 
allows  the  daily  MCCUs  calculated  each  24-hour  period  to  accumulate.  On  request  from 
the  PLOT  PAST  THIRTY-DAY  MCCUS  process,  the  last  30  days  worth  of  MCCUs  are 
taken  from  the  data  store  and  delivered  to  the  process. 

Finally,  the  last  DFD  sub-component  is  the  source/sink.  Sources  and 
sinks  are  found  on  the  edges  of  the  DFD.  They  show  where  desired  data  originate  and 
provide  a  final  recipient  of  the  finished  product  exiting  the  system  [Page-Jones  80], 

DFDs  representing  a  system  can  be  quite  large  and  complicated,  requiring 
a  method  of  partitioning  to  separate  the  large  DFD  into  understandable  sub-components. 
The  entire  DFD  is  started  by  a  context  diagram  indicated  as  level  0  and  partitioned  down 
through  various  layers  until  further  partitioning  is  no  longer  practical.  The  lowest  level 
processes  are  called  functional  primitives  and  are  the  building  blocks  of  the  context  diagram 
[Page-Jones  80].  This  top-down  partitioning  method  will  take  a  single  process  and  will 
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show  the  details  of  that  process  in  the  form  of  a  more  detailed  DFD.  The  small  DFD 
portion  found  in  Figure  4- 1(b)  describes  a  single  process  found  at  the  next  higher  level  of 
the  DFD.  The  numbering  system  is  used  to  denote  hierarchy — sub-elements  from  process 
1.0  are  labelled  1.1,  1.2,  1.3,  etc.,  clarifying  details  of  larger  processes.  The  input  and 
output  data  flows  from  tne  superior  process  are  the  same  for  the  subordinate  sub-com¬ 
ponents.  Appendix  E  contains  the  leveled  DFD  for  the  Resource  Management  DSS.  The 
context  diagram  is  presented  first,  and  each  process  is  leveled  by  describing  it  in  terms  of 
lower-level  data  flows,  processes,  and  data  stores.  Appendix  E  presents  a  logical  view  of 
what  the  system  is  doing.  The  next  section  describes  the  method  used  to  explain  this 
graphical  representation. 

b.  Tools  to  Describe  Policy 

Because  the  DFD  shows  partitioning  of  a  system  only,  some  method  of 
describing  each  functional  primitive  must  be  used  to  specify  the  mechanics  of  the  whole 
system.  Mini-specifications,  or  simply,  mini-specs,  are  used  to  describe  each  functional 
primitive.  Only  functional  primitives  are  described  because  any  other  process  is  a  con¬ 
glomeration  of  functional  primitives  and  violates  the  non-redundancy  rule  of  structured 
specification.  Page-Jones  points  out  that  the  goals  and  objectives  of  the  mini-specs  tool  are 
to  ensure  the  following: 

•  There  must  be  one  mini-spec  for  each  functional  primitive  in  the  DFD. 

•  The  mini-spec  must  state  the  way  in  which  the  data  flows  entering  the  functional 
primitive  are  transformed  into  the  data  flows  leaving  it. 

•  The  mini-spec  should  control  redundancy  by  not  restating  something  already  stated  in 
the  DFD  or  data  dictionary. 

•  The  mini-spec  should  facilitate  descriptions  in  a  standard  manner.  [Page-Jones  80] 
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Mini-specs  can  be  written  in  three  ways:  Structured  English,  the  decision 
tree,  or  the  decision  table.  Structured  English  is  the  method  used  to  write  the  mini-specs 
for  the  Resource  Management  DSS  and  therefore  is  the  only  method  described  here. 

Figure  4-2  is  a  sample  mini-spec  of  the  functional  primitive  CALCULATE 
MCCUS  taken  from  Figure  4-l(b).  The  Structured  English  method  describes  what  the 
functional  primitive  does  to  transform  the  data  flows  going  into  the  process  to  the  data  flow 
leaving  the  process.  Notice  that  the  mini-spec  uses  verbs  where  possible  and  uses  terms 
from  the  data  dictionary  which  have  a  specific  meaning  [Page- Jones  80].  The  mini-spec 
should  be  written  to  tell  the  programmer  what  is  to  be  done  rather  than  how  to  do  it. 
Appendix  F  contains  the  collection  of  mini-specs  explaining  the  functional  primitives  iden¬ 
tified  from  the  set  of  leveled  DFDs. 


1.1  CALCULATE  MCCUS 

For  the  past  24-hour  period  do  the  following: 

1.  Get  number  of  admissions 

2.  Get  number  of  phone  consults 

3.  Get  number  of  inpatients 
4  Get  number  of  live  births 

5.  Get  number  of  outpatient  visits 

6.  Get  number  of  inpatient  visits 

7.  Calculate  the  number  of  MCCUs  earned  by: 

7.1  (Number  of  admissions)  X  ADMISSION_VAL  plus 
72  (Number  of  phone  consults)  X  PHONE_CONSULT_VAL  plus 

7.3  (Number  of  inpatients  -  number  of  admissions)  X  CEN$US_VAL  plus 

7.4  (Number  of  live  births)  X  UVE_BIRTH_VAL  plus 

7.5  (Number  of  outpatient  visits  plus  Number  of  inpatient  visits)  X  CLINIC_VISIT_VAL 


Figure  4-2.  Mini-Spec  for  Process  CALCULATE  MCCUS 
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c.  Data  Dictionary 

A  data  dictionary  is  the  collection  of  all  data  elements  that  are  found  in  the 
DFD,  mini-specs,  or  even  in  the  data  dictionary  itself.  The  data  dictionary  functions  as  a 
repository  for  the  definition  of  all  data  elements.  Data  elements  that  are  a  combination  of 
other  data  elements  are  further  defined  in  the  data  dictionary  until  all  data  elements  are 
described.  The  data  dictionary  is  alphabetized  to  facilitate  ease  of  use.  Appendix  G  con¬ 
tains  the  data  dictionary  for  the  Resource  Management  DSS. 

2.  Module  Specification 

The  second  step  used  in  designing  the  Resource  Management  DSS  was  the 
module  specification.  The  module  specification  uses  two  tools — the  structure  chart  and  a 
written  description  of  the  function  of  each  module.  The  goal  of  module  specification  is  to 
take  the  DFD,  which  has  very  little  procedural  detail,  and  produce  a  structure  chart  which 
has  a  great  deal  of  procedural  detail.  The  structure  chan,  when  accompanied  by  module 
specs,  provides  detail  from  which  a  programmer  can  develop  source  code  [Page- Jones  80]. 
a.  Structure  Chart  Transformed  From  DFD 

By  carefully  studying  the  DFDs,  a  structure  chan  is  drawn  that  depicts  the 
entire  system.  The  structure  chan  is  drawn  to  partition  the  system  into  separate  and 
relatively  independent  modules.  Each  individual  module  is  responsible  for  a  certain  action 
within  the  system  and  represents  a  reasonable  partition  of  source  code  that  will  be  written 
by  the  programmer.  The  structure  chart  shows  the  hierarchy  of  the  modules  and  a  simple 
description  of  each  module  is  provided  through  its  name. 

Figure  4-3  is  a  small  subset  of  the  Resource  Management  DSS  taken  from 
Appendix  H.  The  module  DO  THIRTY-DAY  TREND  MENU  CHOICE  will  contain  the 
program  source  code  that  allows  it  to  call  on  the  subordinate  module  GET  THIRTY-DAY 
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Figure  4-3.  Portion  of  Resource  Management  DSS  Structure  Chart 

TREND  MENU  CHOICE.  This  subordinate  module  will  present  the  user  with  a  menu, 
read  the  user’s  menu  selection,  check  for  valid  input,  and  return  the  valid  choice  to  the 
calling  module  (DO  THIRTY-DAY  TREND  MENU  CHOICE).  Depending  on  the  menu 
selection,  this  module  will  call  upon  either  the  PUT  GRAPH  OF  THIRTY-DAY  MCCU 
TREND  module  or  the  PUT  MCCU  EARNINGS  TO  DATE  module.  Supposing  the  for¬ 
mer  module  is  selected,  the  source  code  in  this  module  will  call  upon  the  GET  MOST 
RECENT  THIRTY-DAY  MCCU  EARNINGS  module,  which  will  extract  the  most  recent 
30  days’  worth  of  daily  MCCU  data  and  pass  it  back  to  the  calling  module,  where  the  data 
will  be  graphed.  This  modularization  breaks  the  entire  system  down  into  smaller  portions, 
facilitating  source  code  development.  The  remainder  of  the  Resource  Management  DSS 
structure  chart  is  found  in  Appendix  H. 

b.  Module  Specification  By  Module  Specs 

Examining  the  structure  chart  alone  will  not  provide  the  needed  informa¬ 
tion  from  which  a  programmer  will  be  able  to  derive  source  code.  An  explanation  of  the 
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individual  module  by  module  specs  must  be  provided  to  give  sufficient  information  to  the 
programmer  [Page- Jones  80].  Pseudocode  is  the  most  often  used  form  of  module  specs. 

Pseudocode  is  a  detailed  method  of  describing  a  module  that  tells  the  pro¬ 
grammer  how  the  module  will  perform  its  function.  It  is  written  in  a  Structured  English 
format  and  can  look  very  similar  to  the  code  itself.  Figure  4-4  provides  a  sample  of  the 
pseudocode  found  in  Appendix  I  documenting  the  Resource  Management  DSS. 


MODULE  DO  THIRTY-DAY  TREND  MENU  CHOICE 


/  *  Finds  out  what  the  user  wishes  to  do  with  MCCU  earning  trends  7 

/  *  Narrows  choices  to  displaying  MCCUs  earned  to  date,  graphing 
recent  trends,  or  quitting  the  menu  */ 


Get  a  valid  menu  pick 


If  not  quit  then 

If  request  for  recent  MCCU  earning  trends 
then  call  module  to  graph  thirty-day 
MCCU  trend 

Else  If  request  for  MCCUs  earned  to  date  then 
call  module  to  display  MCCU  eamlngs 
to  date 

END  MODULE 


Figure  4-4.  Sample  Module-Spec  By  Pseudocode 


C.  DECISION  SUPPORT  SYSTEM  (DSS)  ARCHITECTURE 

The  data,  dialog,  and  modeling  components  of  DSS  architecture  are  also  a  convenient 
method  of  partitioning  a  DSS  for  design.  The  system  specifically  addresses  the  three  major 
components  of  a  DSS  for  designers  to  construct  individual  system  requirements.  The 
Resource  Management  DSS  is  described  in  this  section  by  focusing  on  the  data,  dialog,  and 


modeling  components.  Each  is  described  in  detail  and  construction  requirements  are 
discussed. 

1.  Data  Component 

a.  Description 

The  data  needed  to  support  the  Resource  Management  DSS  design  will  be 
extracted  from  a  variety  of  reports  and  MIS  in  the  hospital.  At  present,  the  proposed  data 
extraction  method  consists  of  information  systems  personnel  setting  up  the  required  data¬ 
bases  in  support  of  the  the  Resource  Management  DSS  and  assigning  a  database  adminis¬ 
trator.  The  context  diagram  of  the  DFD  found  in  Appendix  E  identifies  the  different 
sources  of  necessary  data.  The  database  administrator  will  maintain  the  required  databases 
to  support  the  Resource  Management  DSS. 

During  the  analysis  phase,  redundant  sources  of  data  elements  were  dis¬ 
covered.  Many  data  elements  identified  in  the  locally  generated  reports  were  also  found  in 
the  hospital  MIS.  The  locally  generated  reports  could  be  replaced  by  hospital  MIS  once 
data  accuracy  is  verified.  Using  hardware  to  automatically  extract  data  from  the  hospital 
MIS  was  not  investigated  for  feasibility.  The  procedures  and  programs  to  perform  the 
extraction  of  data  are  left  for  future  research. 

b.  Construction 

Four  separate  databases  must  be  set  up  to  support  the  first  iteration  of  the 
Resource  Management  DSS:  Two  MCCU  databases  and  two  productivity  databases  will 
have  to  be  established  in  order  to  provide  a  source  of  current  MCCU  and  productivity 
information. 

The  first  MCCU  database,  DAILY  MCCU  ANALYSIS  FILE,  will  consist 
of  MCCU  earnings  of  the  hospital  each  day  for  the  current  fiscal  year.  Daily  MCCUs  must 
be  calculated  and  added  to  the  database  each  24-hour  period.  The  maximum  number  of 


days’  worth  of  data  will  be  365  days  and  the  minimum  30  days.  In  order  to  calculate  the 
most  recent  30-day  MCCU  earning  trends,  this  database  must  have  as  a  minimum  the  last 
30  days’  daily  MCCU  earnings  on  file. 

The  second  MCCU  database,  MONTHLY  MCCU  ANALYSIS  FILE,  is 
composed  of  the  entire  hospital’s  monthly  earnings  of  MCCUs  for  the  current  and  previous 
fiscal  years.  As  a  maximum,  this  database  will  have  24  months  of  data  and  as  a  minimum 
it  will  contain  12  months  of  data. 

The  two  productivity  databases  will  require  the  past  24  months’  produc¬ 
tivity  data  by  individual  clinics  as  well  as  hospital-wide.  The  CLINIC  PRODUCTIVITY 
ANALYSIS  FILE  will  maintain  the  past  24  months’  worth  of  productivity  for  each  clinic  in 
terms  of  monthly  work  units  accomplished  divided  by  the  average  number  of  health-care 
providers  in  the  clinic  that  month.  Productivity  will  have  to  be  calculated  and  added  to  the 
database  as  the  monthly  totals  become  available.  As  another  month  is  added,  the  oldest 
month  can  be  deleted  from  the  database. 

The  HOSPITAL  PRODUCTIVITY  ANALYSIS  FILE  will  contain  the 
hospital  productivity  values  for  the  past  24  months  in  the  same  manner  as  the  clinical 
database.  The  most  recent  24  months’  worth  of  productivity  will  be  kept. 

2.  Dialog  Component 
a.  Description 

The  importance  of  the  dialog  component  cannot  be  overstated.  If  the 
interaction  between  the  user  and  DSS  is  difficult,  the  DSS  will  most  likely  fall  into  disuse. 
The  dialog  component  of  the  Resource  Management  DSS  was  analyzed  in  terms  of  user 
^  computer  experience  and  estimated  frequency  of  use.  During  interviews,  levels  of  com¬ 

puter  experience  were  discovered  from  potential  users  and  a  dialog  method  commensurate 
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with  this  skill  level  was  determined.  A  menu-driven  dialog  was  chosen  that  would  guide 
the  Resource  Management  DSS  user  through  the  different  levels  of  the  system. 


The  choice  of  a  menu-driven  dialog  was  made  because  this  allowed 
resource  managers  not  experienced  with  computers  to  easily  learn  and  use  the  system.  A 
menu-driven  dialog  will  also  alleviate  the  requirement  of  learning  and  relearning  complex 
commands  by  infrequent  system  users  and  new  users  alike.  The  implementation  of  the 
Resource  Management  DSS  should  be  flexible  enough  to  use  a  menu-driven  dialog  com¬ 
bined  with  an  interactive  query  type  of  dialog  when  necessary. 
b.  Construction 

The  menu-driven  dialog  will  be  constructed  to  provide  a  reasonable  num¬ 
ber  of  menu  options  (the  magical  number  seven  plus  or  minus  two)  so  as  not  to  overburden 
the  user’s  capacity  to  process  information  [Miller  56].  A  menu-driven  dialog  will  guide  the 
user  through  the  various  levels  of  the  Resource  Management  DSS.  Where  appropriate, 
simple  choices  are  selected  from  the  menu,  or  the  user  is  queried  for  input. 

An  example  using  the  menu-driven  dialog  style  is  getting  subjective  pre¬ 
dictions  of  future  months’  MCCU  earnings.  The  menu-driven  dialog  will  guide  the  user  to 
the  level  of  selecting  the  option  of  forecasting  future  MCCU  earning  trends  based  on  the 
user’s  subjective  predictions  of  the  next  two  months’  MCCU  earnings.  The  system  will 
query  the  user  to  input  the  next  two,  three,  or  four  months’  worth  of  MCCUs  predicted  by 
the  user.  The  dialog  component  will  read  these  inputs,  check  for  validity,  and  project 
MCCU  earnings  a  selected  number  of  months  beyond  user  predictions.  At  all  menu  levels, 
the  option  to  exit  the  program  will  be  available,  as  well  as  the  option  to  return  to  previous 
menu  screens  where  appropriate. 

The  use  of  case  statements  found  in  programming  languages  such  as 
PASCAL  will  enhance  the  maintainability  of  the  system.  Modules  responsible  for 
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displaying  menu  choices  and  reading  user  selection  can  be  easily  changed  by  adding  to  or 
deleting  from  menu  selections. 

3.  Modeling  Component 

a.  Description 

The  modeling  component  of  the  Resource  Management  DSS  architecture 
will  be  capable  of  giving  the  user  a  choice  of  modeling  applications.  For  example,  in  the 
case  of  forecasting  future  monthly  MCCU  earnings,  the  user  will  be  offered  the  opportu¬ 
nity  to  base  the  forecast  on  varying  months  of  historic  data  or  on  varying  months  of  user 
input  predictions.  Different  lengths  of  future  periods  to  be  forecast  will  also  be  presented 
to  the  user. 

The  overall  goal  of  the  modeling  component  is  to  not  force  the  user  into  a 
specific  modeling  construct.  The  user  should  be  offered  the  opportunity  to  choose  from 
several  different  types  of  models  that  best  suit  user  needs.  There  is  no  sense  in  requiring 
the  user  to  predict  the  next  six  months  worth  of  productivity  if  only  one  month  in  the  future 
is  required.  The  priority  will  be  getting  the  most  accurate  data  analysis  possible  from  the 
model  base. 

b.  Construction 

The  construction  of  the  modeling  component  will  be  such  that  a  single 
model  is  represented  by  a  module  in  the  structure  chart.  This  method  will  facilitate  the  use 
of  different  models  for  desired  applications  and  allow  changes  to  existing  models  or  addi¬ 
tions  of  new  ones.  Future  iterations  should  allow  the  user  to  identify  the  need  to  use  a 
general  type  of  model  and  allow  a  search  of  the  model  base  for  a  specific  application  the 
user  requires.  A  model  base  consisting  of  many  useful  models  will  enhance  the  usability  of 
the  system.  The  Resource  Management  DSS  will  possess  the  characteristics  of  a  tailor- 
made  system,  aiding  users  in  finding  and  applying  appropriate  models. 
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D.  SUMMARY 

The  ir  Jn  thrust  of  this  chapter  was  to  take  a  portion  of  the  Resource  Management 
DSS  from  the  analysis  phase  into  the  design  phase.  This  chapter  identified  the  first  itera¬ 
tion  of  the  system  to  be  designed,  transformed  the  analysis  into  design  using  structured  and 
module  specification  methods,  and  described  the  architecture  of  the  Resource  Management 
DSS. 

The  structured  specification  describes  the  logical  design  of  the  system  using  the  data 
flow  diagram  (DFD).  The  DFD  presents  a  graphic  description  of  the  overall  system,  taking 
the  view  down  through  several  layers.  Mini-specs  aid  in  further  describing  this  graphic 
presentation. 

The  module  specification  phase  takes  the  documentation  from  the  structured  specifi¬ 
cation  phase  and  furii.er  describes  the  developing  Resource  Management  DSS.  The  mod¬ 
ule  specification  describes  how  the  system  was  to  perform  desired  functions  using  the 
structure  chart  and  module  specs.  From  these  two  by-products  of  the  module  specification, 
follow-on  researchers  will  easily  produce  source  code  to  implement  the  first  iteration  of  the 
Resource  Management  DSS. 

The  final  section  of  this  chapter  discussed  the  actual  construction  of  the  three  DSS 
architecture  components  which  were  described  in  Chapter  II.  Within  the  data  component, 
the  four  databases  required  for  the  first  iteration  of  the  Resource  Management  DSS  were 
described.  The  dialog  component  was  designed  to  guide  the  user  through  the  different  lev¬ 
els  of  the  system  by  using  a  menu  dialog  interaction  between  user  and  system.  The  last 
DSS  architecture  component,  the  modeling  component,  was  designed  to  use  separate  mod¬ 
ules  within  the  source  code  to  perform  desired  modeling  functions  on  extracted  data.  As 
the  Resource  Management  DSS  develops,  a  model  base  will  allow  the  user  to  choose  iiom 
a  variety  of  models. 
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It  must  be  emphasized  the  design  presented  in  this  chapter  is  for  Version  0,  the  first 
of  many  iterations  through  which  the  Resource  Management  DSS  must  pass  prior  to 
becoming  the  ultimate  system  envisioned  by  both  user  and  builder.  Continuous  interaction 
between  user  and  builder  will  serve  to  enhance  the  effectiveness  of  the  Resource  Manage¬ 
ment  DSS  and,  as  a  result,  enhance  the  effectiveness  of  the  quality  of  decisions  made  by 
upper-level  managers  at  SBHACH. 
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V.  SUMMARY  OF  RESEARCH  AND 
RECOMMENDATIONS  FOR  FUTURE  STUDY 


The  thesis  research  presented  in  the  previous  chapters  documented  the  development 
of  the  Resource  Management  Decision  Support  System  (DSS)  from  inception  to  design. 
The  need  for  a  computer-based  system  to  aid  Silas  B.  Hays  Army  Community  Hospital 
(SBHACH)  resource  managers  was  discussed,  and  methodologies  for  identifying  critical 
information  needs  of  decision  makers  were  presented.  Data  was  collected  through  struc¬ 
tured  interviews  and  analyzed  in  order  to  derive  the  hospital’s  Critical  Success  Factors 
(CSFs).  Finally,  proposed  measures  were  discussed  that  would  give  decision  makers  the 
ability  to  analyze  data  necessary  to  satisfy  identified  CSFs  and  the  first  iteration  of  the 
Resource  Management  DSS  was  designed. 

A.  SUMMARY  OF  RESEARCH 

This  section  of  the  thesis  emphasizes  the  important  factors  discovered  during  the 
course  of  the  thesis  research.  The  areas  briefly  discussed  are  the  methodology  used  to 
derive  SBHACH  CSFs,  the  design  of  the  first  iteration  of  the  Resource  Management  DSS, 
the  value  of  the  thesis  research,  and  the  suggested  implementation  procedure  for  the 
Resource  Management  DSS. 

1.  Derivation  of  CSFs 

The  methodology  used  to  derive  CSFs  trom  SBHACH  resource  managers  was 
the  structured  interview.  Six  upper-level  managers  were  interviewed.  The  data  collected 
during  interviews  was  used  to  develop  the  individual  managers’  CSFs.  Summaries  of  the 
interviews  are  found  in  Appendix  C. 


The  next  step  in  determining  the  hospital’s  CSFs  was  to  move  from  a  manager’s 
focus  of  CSFs  to  an  organizational  focus.  As  discussed  by  Bullen  and  Rockart,  the  indi¬ 
vidual  CSFs  are  aggregated  and  from  this  compilation  organizational  CSFs  are  derived 
[Bullen  81].  Each  manager’s  CSFs  were  analyzed  and  a  master  list  of  prioritized  CSFs  for 
the  hospital  was  derived.  Once  organizational  CSFs  were  listed,  proposed  measures  that  a 
computer  system  should  possess  to  satisfy  CSFs  were  developed.  Table  5-1  summarizes 
the  four  CSFs  derived  from  the  research  and  presents  the  proposed  measures  to  satisfy 
these  organizational  CSFs  for  SBHACH. 

TABLE  5-1 

CRITICAL  SUCCESS  FACTORS  AND  PROPOSED  MEASURES 


Critical  Success  Factors 


Proposed  Measures 


CSF  1  Maintain  sufficient  fiscal  resources 
to  meet  the  demands  for  inpatient 
and  outpatient  health-care  services. 


•  Compare  current  clinic  work  unit  levels 
to  historic  values. 

•  Forecast  future  clinical  productivity 
using  historic  data  and  user-projected 
values. 

•  Forecast  future  hospital  productivity 
using  historic  data  and  user-projected 
values. 

•  Compare  current  MCCU  data  to 
historical  data  and  projected  goals. 

•  Project  future  MCCU  values  based  on 
current  trends  of  MCCU  earnings  and 
user-projected  values. 

•  Calculate  unused  capacity  in  the  form  of 
bed  space  and  potential  discharge 
information. 

•  Calculate  projected  bed  space  required 

based  on  current  trends.  ! 
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TABLE  5-1  (Continued) 

CRITICAL  SUCCESS  FACTORS  AND  PROPOSED  MEASURES 


Critical  Success  Factors 


Proposed  Measures 


CSF  2  Maintain  sufficient  military  and 
civilian  personnel  to  adequately 
provide  health-care  services  to 
fluctuating  inpatient  and  outpatient 
levels. 


CSF  3  Monitor  the  impact  of  the  Primary 
Care  to  Uniformed  Services  (PRI¬ 
MUS)  clinics  and  the  Civilian 
Health  And  Medical  Program  of 
the  Uniformed  Services  (CHAM- 
PUS)  reform  initiative. 


CSF  4  Maintain  a  sufficient  amount  of 
medical  equipment,  in  proper 
working  order,  to  provide  neces¬ 
sary  health-care  services  to  inpa¬ 
tient  and  outpatient  demands. 


•  Project  gains/losses  for  six  months  in 
the  future  for  military  and  civilian 
personnel. 

•  Forecast  clinical  staffing  levels  from 
historical  data  and  user-projected  input 

•  Compare  different  clinical  productivity 
levels  at  the  same  time. 

•  Measure  the  daily  fluctuation  of  clinic 
productivity  in  work  units  compared  to 
historical  values. 

•  Forecast  the  number  of  outpatients  in 
the  future  hased  on  historical  referrals 
from  the  PRIMUS  clinics. 

•  Measure  the  daily  fluctuation  of  clinic 
MCCUs  earned  compared  to  historical 
values. 

•  Project  trends  of  outpatient  drops  due  to 
loss  of  outpatients  to  PRIMUS. 

•  Forecast  future  monthly  budget  expen¬ 
ditures  on  capital  equipment  based  on 
historical  data. 

•  Forecast  future  monthly  budget  expen¬ 
ditures  on  capital  equipment  based  on 
projected  user  input. 


2.  Design  of  First  Iteration 

The  methodologies  used  to  design  the  first  iteration  of  the  Resource  Manage¬ 
ment  DSS  were  the  structured  specification  and  the  module  specification.  Figure  5-1  illus¬ 
trates  the  use  of  these  two  methodologies  producing  documentation  from  which  further 
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Systems  Systems 

I  Analysis  Design  , 


Figure  5-1.  Transitions  From  Systems  Analysis  to  Systems  Design 


design  is  conducted,  stopping  short  of  source  code  development.  The  proposed  measures 
developed  from  the  CSFs  are  analyzed  and  the  data  flow  diagram,  mini-specs,  and  data 
dictionary  are  developed  from  the  structured  specification. 

Further  design  is  conducted  by  using  output  of  the  structured  specification 
phase  as  input  to  the  module  specification  phase.  Finally,  the  structure  chart  and  module 
specifications  are  developed.  From  these  five  outputs  of  structured  design,  the  Resource 
Management  DSS  for  SBHACH  may  be  implemented.  The  documentation  found  in 
Appendices  E,  F,  G,  H,  and  I  is  used  to  describe  the  Resource  Management  DSS  in  terms 
of  the  data,  dialog,  and  modeling  components  found  in  Figure  5-2.  The  databases  for  the 
Resource  Management  DSS  are  identified  in  the  data  component,  and  the  different  dialog 
styles  and  mode’s  used  are  listed  in  the  dialog  and  modeling  components. 

During  the  structured  design  phase,  four  databases  were  identified  that  will  need 
to  be  established  in  order  to  support  the  Resource  Management  DSS.  Data  extracted  from 
various  reports  and  MIS  (see  Figure  5-2)  will  be  put  into  these  four  databases.  The  two 
MCCU  databases  will  supply  data  to  graphically  illustrate  recent  and  historic  MCCU  earn¬ 
ing  trends.  The  clinic  and  hospital  monthly  productivity  databases  will  be  used  to  analyze 
both  individual  clinic  and  hospital  productivity  values  over  varying  time  periods. 


I 
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Figure  5-2.  Resource  Management  DSS  Components 


The  dialog  component  for  the  Resource  Management  DSS  will  provide  the 
capability  of  guiding  the  user  through  various  levels  of  menus  in  order  to  view  required 
data.  The  menu-driven  dialog  was  chosen  as  the  method  of  communication  between  user 
and  system  due  to  the  ease  of  interaction  and,  more  importantly,  because  this  specific 
method  supports  novice  computer  users  and  infrequent  users  alike.  Making  the  dialog 
component  simple  to  use  stresses  flexibility  in  allowing  various  managers  to  use  the 
Resource  Management  DSS  and  accommodates  the  frequent  job  changes  found  in  most 
military  environments. 

The  most  important  aspect  of  the  modeling  component  was  the  development  of 
a  model  base  type  of  management  system.  As  the  Resource  Management  DSS  is  imple¬ 
mented,  different  models  will  be  added  to  the  system  and  existing  ones  will  be  modified. 
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The  modeling  component  of  the  Resource  Management  DSS  is  built  to  incorporate  a  single  , 

I 

model  within  a  module  of  source  code.  This  flexibility  will  allow  system  maintainers  to  I 

make  modeling  changes  easily. 

3.  Value  of  Research 

t 

The  research  conducted  will  primarily  aid  upper-level  managers  at  SBHACH.  I 

Once  implemented,  the  Resource  Management  DSS  will  provide  resource  managers  the 
ability  to  analyze  relevant  data  for  ill-structured  decision  problems  commonly  found  in  the 
hospital  administration  field  and  manipulate  this  data  in  different  manners.  The  overall  I 

value  of  the  research  will  ultimately  be  the  improved  decision-making  quality  the  Resource 
Management  DSS  will  lend  to  upper-level  managers  at  SBHACH.  The  design  of  the 
Resource  Management  DSS  proposes  timely  access  to  relevant  data  that  was  not  available  I 

prior  to  this  research.  The  added  capability  of  manipulating  data  in  various  ways  will  allow 
the  system  users  to  make  ad  hoc  queries  into  different  databases  and  ask  “What  if?”  ques¬ 
tions  when  required.  1 

4.  Implementation  Procedures 

The  logical  next  step  of  developing  the  Resource  Management  DSS  is  to  imple¬ 
ment  the  system  by  writing  source  code  and  to  deliver  the  system  to  the  users  for  review. 

The  system  documentation  developed  in  the  design  phase  should  be  sufficient  for  the  easy 
development  of  source  code.  The  decision  must  be  made  as  to  which  programming  lan¬ 
guage  will  be  used.  It  is  possible  the  first  iteration  could  be  developed  in  more  than  one 
programming  language  and  results  compared. 

Once  the  first  iteration  is  implemented,  the  delivered  product  should  be  delivered 
to  the  user  for  review.  After  getting  user  feedback,  the  first  iteration  could  be  built  on  to 
include  user  changes  and  proposed  measures  to  satisfy  more  of  the  first  CSF  as  well  as 
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other  CSFs.  This  iterative  process  will  foster  the  evolution  of  a  DSS  that  truly  reflects 
SBHACH  user  requirements. 

B.  OPPORTUNITIES  FOR  FUTURE  RESEARCH 

The  research  presented  in  the  thesis  represents  the  first  of  several  iterations  that  will 
be  conducted  before  the  Resource  Management  DSS  evolves  into  a  fully  functioning  Deci¬ 
sion  Support  System.  During  the  course  of  research,  some  areas  were  identified  that  may 
lead  to  future  research;  automating  the  data  extraction  task  and  defining  the  tasks  of  the 
database  administrator  are  two  examples. 

1.  Data  Extraction 

There  is  no  automated  data  extraction  method  that  extracts  data  from  the  various 
sources  in  the  hospital.  The  different  MIS  at  the  hospital  provide  data  as  well  as  the  previ¬ 
ously  identified  reports  (see  Figure  5-2).  Further  research  in  this  area  could  identify  which 
data  sources  provide  the  most  accurate  data  and  discover  methods  of  extracting  data  auto¬ 
matically  from  the  various  MIS  in  use  at  the  hospital.  Adding  modules  to  the  commercial 
MIS  was  ruled  out  due  to  violating  commercial  contracts  with  system  mainfainers.  Detailed 
studies  might  identify  methods  of  extracting  the  data  from  the  different  MIS  without  vio¬ 
lating  these  commercial  contracts. 

2.  Establishing  Duties  of  Database  Administrator 

The  intention  of  the  hospital  is  to  implement  a  local  area  network  with  terminals 
provided  to  key  resource  managers  within  the  hospital.  The  Resource  Management  DSS  is 
one  of  several  software  packages  that  will  be  used  on  the  network  (electronic  mail  would 
also  be  included).  Further  research  could  identify  the  duties  and  operating  procedures  of 
the  assigned  database  administrator  of  the  local  area  network.  This  research  would  be 
instrumental  in  establishing  and  maintaining  the  many  databases  that  will  be  created  by 
future  iterations  of  the  Resource  Management  DSS. 


P 
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APPENDIX  A 


INITIAL  FACT-FINDING  INTERVIEW 
A.  DESCRIPTION 

This  appendix  summarizes  the  initial  interview  conducted  on  1  March,  1988,  by  the 
author  to  discuss  information  management  problems  at  Silas  B.  Hays  Army  Community 
Hospital  (SBHACH).  Attendees  were  the  Chief  of  Resource  Management  Division  and  the 
Chief  of  Clinical  Support  Division.  Names  of  the  resource  managers  holding  these  billets 
have  been  omitted  though  nothing  inappropriate  was  discussed. 

An  important  point  the  interview  brought  out  was  the  current  method  the  Department 
of  Defense  (DOD)  uses  to  reimburse  health-care  services  provided  by  SBHACH.  The 
current  system.  Medical  Care  Composite  Units  (MCCUs),  was  described  as  archaic  and 
difficult  to  use  by  resource  managers.  The  major  problem  of  the  MCCU  method  is  that  it 
does  not  provide  a  breakdown  by  operational  department  that  may  be  used  by  managers  as 
a  monitoring  tool.  The  feedback  from  DOD  is  a  lump  sum  by  quarter  of  what  each  Medical 
Treatment  Facility  (MTF)  has  earned. 

The  ideal  system  the  interviewees  described  would  separate  “winners”  from  “losers” 
in  terms  of  outputs  to  inputs.  Managers  want  the  ability  to  analyze  each  operational 
department  and  determine  if  the  outputs  in  the  form  of  health-care  services  rendered  are 
equal  to  the  number  of  MCCUs  earned.  They  also  summarized  in  the  interview  the  other 
areas  of  information  management  they  wanted  the  proposed  system  to  provide. 
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B .  SUMMARY  OF  INTERVIEW 


The  purpose  of  the  meeting  was  to  identify  what  requirements  upper-level 
management  (Hospital  Commander  and  Executive  Officer)  wanted  from  existing 
information  systems  and  what  could  be  done  to  solve  information  needs. 

They  noted  that  due  to  budget  constraints,  managers  at  SBHACH  were  essentially 
forced  to  make  use  of  existing  Management  Information  Systems  (MIS),  i.e.,  no  funding 
was  available  for  a  new  MIS.  Given  this,  they  want  the  development  of  some  method  for 
identifying  “winners”  and  “losers”  in  terms  of  the  operational  medical  departments  in  the 
MTF.  He  explained  that  Medical  Care  Composite  Units  (MCCUs)  are  how  the  DOD 
allocates  budget  funding  to  Medical  Treatment  Facilities  (MTFs).  They  next  described  in 
detail  the  current  method  the  MCCU  system  used  to  earn  DOD  reimbursement  for 
SBHACH.  When  health-care  providers  (doctors,  nurses,  lab  technicians...)  provide 
services  to  patients  in  the  form  of  consults,  surgery,  pharmaceutical  prescriptions,  bed 
space,  x-rays,  and  other  varied  services,  the  hospital  is  credited  with  MCCUs  depending 
on  the  type  of  service.  For  example,  an  outpatient  visit  is  worth  0.3  MCCUs,  a  live  birth  is 
valued  at  10  MCCUs,  and  an  admission  is  worth  10  MCCUs  the  first  day  and  1  MCCU 
every  day  thereafter. 

Data  that  determines  the  number  of  MCCUs  provided  is  maintained  daily  on  an 
information  system  called  the  Uniform  Chart  of  Accounts  Performance  Expense  Reports 
System  (UCAPERS).  This  data  is  input  by  type  and  cost  of  service  provided.  The 
information  is  updated  daily,  and  monthly  a  tape  summarizing  all  health-care  services 
provided  is  sent  to  a  DOD  run  facility  that  calculates  the  data  into  MCCUs.  This  data,  in 
the  form  of  MCCUs,  is  then  used  by  DOD  personnel  to  provide  monetary  funding  to 
SBHACH  in  reimbursement  for  health-care  services  provided  at  the  hospital.  A  hard-copy 
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report  comes  back  to  the  hospital  summarizing  the  previous  quarter  by  the  amount  of 
MCCUs  the  entire  MTF  earned. 

They  acknowledged  the  MCCU  method  is  archaic.  The  financial  benefits  are  in  direct 
conflict  to  modem  medical  treatment  practices;  for  example,  the  hospital  will  get  more 
“points”  for  admitting  a  patient  than  for  treating  him/her  as  an  outpatient 

They  next  pointed  out  that  the  information  they  want  is  supplied  in  part  on  two  of  the 
MIS  in  the  hospital,  UCAPERS  and  the  Automated  Quality  of  Care  Evaluation  Support 
System  (AQCESS). 

“Winners”  are  those  departments  that  provide  health-care  services  which  earn  an 
MCCU  value  equal  or  greater  than  services  expended.  “Losers”  are  those  health-care 
services  which  are  provided  and  either  do  not  earn  an  equal  amount  of  MCCUs  or  are  not 
reimbursable.  They  noted  that  generally  an  admission  into  the  hospital  and  a  stay  of  over 
four  days  represented  a  loss  of  MCCUs  to  the  hospital  after  the  fourth  day.  The  problem 
for  resource  managers  is  they  cannot  dictate  that  medical  services  above  a  certain  threshold 
will  not  be  performed.  The  specialists  would  lose  their  expertise  and,  more  importantly, 
there  would  be  tremendous  social  ramifications  in  denying  medical  services.  They  pointed 
out  that  even  though  hospital  managers  have  a  general  idea  of  the  financial  position  die 
hospital  is  in,  the  feedback  from  the  MCCU  method  is  not  timely  (quarterly  basis)  and  may 
conflict  with  management  estimates. 

The  system  they  envision  would  provide  reports  at  least  on  a  quarterly  basis  and 
would  provide  the  following  information: 

•  Identify  by  department  and/or  physician  the  workload  performed; 

•  Show  which  health-care  services  performed  are  reimbursed  in  terms  of  MCCUs; 

•  Show  which  services  are  not  reimbursed; 

•  Use  outputs  to  monitor  progress  of  departments  which  are  financial  sinks; 
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•  Use  outputs  to  recognize  departments  which  are  performing  well. 

The  last  part  of  the  meeting  was  spent  identifying  specific  data  that  should  be 
incorporated  into  the  DSS.  Table  A-l  summarizes  the  type  of  measurements  upper-level 
management  was  looking  for. 

TABLE  A-l 

QUANTITATIVE  MEASURES  REQUESTED 
BY  UPPER-LEVEL  MANAGERS 

Inpatient  Revenue/patient  day  Outpatient  revenue/visit 

Number  of  admissions  Census  (number  of  beds) 

Length  of  stay  Mean  hospital  salary 

Mean  hospital  salary  for  community  Wage  expenses  by  department 

Hours  worked  by  department  Supply  expenses  by  department 

Number  of  unfilled  positions  Turnover  rate 

Absentee  rate  Nursing  work  hours/patient  day 

In  addition  to  the  requirements  in  Table  A-l,  they  also  mentioned  that  it  would  be 
convenient  to  have  a  measurement  of  the  average  clinic  waiting  time  for  a  patient,  loss  of 
workload  due  to  unused  health-care  provider  capacity,  and  the  number  of  unused 
appointments. 


APPENDIX  B 


STRUCTURED  INTERVIEW  FORM 

I.  DESCRIPTION 

This  appendix  contains  structured  questions  for  the  conduct  of  interviews  at  Silas  B. 
Hays  Army  Community  Hospital  (SBHACH).  Questions  were  developed  to  determine 
management  Critical  Success  Factors  (CSFs)  [Bullen  81,  Rockart  79,  Rockart  82,  and 
Roc  kart  and  Treacy  82]. 

II.  QUESTIONS  USED  IN  INTERVIEWS 

A.  Industry 

1 .  In  what  areas  will  a  failure  hurt  you  the  most  in  your  job? 

B .  Competitive  Strategy  and  Industry  Position 

1 .  How  do  you  view  your  job  and  the  organization  as  a  whole?  Do  you 
function  as  a  caretaker  or  strategic  planner? 

2.  What  are  your  formal  and  informal  operational  goals  over  the  next  1? 
months? 

3 .  What  information  do  you  need  to  maintain  Silas  B.  Hays  in  the  position  of  a 
competent  provider  of  health-care  services?  Do  community  factors  affect 
you?  If  yes,  how  much  are  you  affected  by  the  community? 

C.  Environmental  Factors 

1 .  What  information  is  necessary  for  managing  resources  in  the  health-care 
industry? 


2 .  What  budget  constraints  do  you  face  in  yo'-r  job? 

3 .  Are  there  certain  health-care  services  that  are  not  economical  to  fund? 

4 .  How  do  changes  in  patient  levels  affect  your  job? 


D.  Temporal  Factors 

1 .  What  current  problems  demand  your  attention  now? 

2 .  What  latest  crises  are  you  addressing  presently? 

E.  Managerial  Position 

1 .  What  is  your  role  in  the  overall  organization? 

2 .  What  information  do  you  need  to  perform  your  job? 

3 .  Where  do  you  get  this  information  from? 

4 .  What  kinds  of  information  are  you  asked  to  calculate,  process,  and  present 
the  most? 

5 .  Is  the  data  readily  available  in  the  form  you  need  or  does  it  need  to  be  pro¬ 
cessed?  If  yes,  how  much  processing  is  necessary? 

6 .  Do  you  require  mostly  current  data  or  historical  data  in  your  job? 

7 .  What  techniques  do  you  use  to  solve  the  biggest  problems  confronting  you? 
Where  do  you  go  to  find  the  information  necessary  to  do  this? 

8 .  Do  you  get  information  you  need  fast  enough? 

F .  Internal  and  External  Factors 

1 .  What  areas  affect  your  job  the  most  that  you  are  unable  to  control? 

2.  In  the  areas  that  you  can  control,  what  items  do  you  find  a  need  to  control 
the  most? 

G .  Monitoring  and  Building  Factors 

1 .  What  best  describes  your  job?  Is  it  a  function  of  monitoring  by  reporting 
findings  to  seniors  or  do  you  do  more  planning  by  looking  at  trends  and 
forecasting  future  developments  and  requirements? 

2.  What  are  the  most  important  things  to  find  out  when  you  come  back  from  an 
extended  leave  or  TDY  period? 

3 .  What  methods  do  you  use  to  measure  success  or  failure? 


I 


4.  What  kind  of  soft  data  do  you  like  to  know?  Do  you  rely  on  word  of 
mouth,  rumors,  personal  observations  of  staff,  or  other  soft  inputs? 
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APPENDIX  C 


SUMMARY  OF  CRITICAL  SUCCESS  FACTOR  INTERVIEWS 

A.  DESCRIPTION 

This  appendix  summarizes  the  six  interviews  conducted  with  senior  resource  man¬ 
agers  at  Silas  B.  Hays  Army  Community  Hospital  (SBHACH).  These  interviews  were 
used  to  develop  organizational  critical  success  factors.  A  separate  interview  summary  is 
provided  for  each  resource  manager  interviewed.  The  interviews  are  presented  in  the  order 
in  which  they  were  conducted.  Names  of  the  resource  managers  holding  the  billets  have 
been  omitted  though  there  is  nothing  inappropriate  in  any  of  the  interviews. 

B .  SUMMARY  OF  INTERVIEW  WITH  THE  NURSING  METHODS 

ANALYST 

The  Nursing  Methods  Analyst  works  in  the  Resource  Management  Division.  The  job 
she  is  performing  is  a  follow-on  tour  after  receiving  a  Master  of  Science  in  Nursing 
Administration. 

1.  Industry  Factors 

The  Nursing  Methods  Analyst  pointed  out  that  SBHACH  does  not  have  a  char¬ 
ter  narrowly  defining  goals  and  objectives,  so  it  was  difficult  for  her  to  define  industry 
factors  that  affect  her  job.  This  motivated  her  to  explain  that  the  hospital  is  responsible  for 
satisfying  those  general  health-care  requirements  that  active  duty,  dependent,  and  retiree 
personnel  need.  Proper  health  care  to  this  population  in  the  surrounding  community  was 
first  and  foremost  in  the  hospital’s  objectives. 
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2.  Competitive  Strategy  and  Industry  Position: 


She  described  the  overall  strategy  of  SBHACH  as  providing  support  to 
inpatients  over  outpatients  and  the  staffing  of  the  workcenters  that  provide  direct  patient 
support  over  those  that  provide  administrative  support. 

3.  Environmental  Factors 

There  are  certain  factors  in  her  job  over  which  she  has  no  control.  She  depends 
on  reports  from  which  she  extracts  data  from  to  generate  her  own  reports.  This  aspect  of 
her  job  was  considered  frustrating  because  she  could  not  control  the  timing,  accuracy,  or 
flow  of  this  information. 

She  went  on  to  point  out  that  the  Hospital  Commander  required  the  hospital  to 
provide  certain  types  of  health-care  services  that  are  losing  propositions.  For  example,  the 
neurology  clinic  does  not  see  enough  patients  to  justify  its  presence  in  the  hospital,  yet  the 
Hospital  Commander  has  decided  to  continue  this  support  in  order  to  satisfy  sporadic 
community  needs.  Closing  this  clinic  and  similar  nonproductive  clinics  would  have  a  neg¬ 
ative  impact  on  the  reputation  of  the  hospital. 

Another  important  source  of  outside  influence  comes  from  the  Health  Services 
Command  (HSC).  For  example,  HSC  has  dictated  to  all  Medical  Treatment  Facilities 
(MTFs)  that  they  provide  two  areas  of  support  in  AIDS  testing.  Fenced  budget  allocations 
arc  provided  to  test  active  duty  personnel  at  Fort  Ord  for  exposure  to  the  AIDS  virus.  This 
includes  documenting  the  results  and  providing  counseling  and  follow-on  medical  services 
for  active  duty  members  exposed  to  the  virus.  The  second  initiative  in  the  AIDS  arena  is  to 
require  testing  of  all  active  duty  inpatients  and  to  strongly  suggest  testing  for  dependent  and 
retiree  inpatients.  The  purpose  is  to  identify  any  inpatients  who  may  carry  the  AIDS  virus 
so  health-care  providers  can  take  appropriate  preventive  measures  while  working  with  body 
fluids. 
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4.  Temporal  Factors 


She  discussed  two  temporal  factors  affecting  her  job:  the  implementation  of  the 
Automated  Quality  of  Care  Evaluation  Support  System  (AQCESS)  and  getting  a  reporting 
system  accepted  that  she  has  developed  to  report  on  clinic  productivity. 

The  AQCESS  system  used  to  require  an  inordinate  amount  of  her  time  moni¬ 
toring  the  progress  of  implementation  and  transition  to  users  at  the  hospital  clinics.  This 
system,  developed  by  contractors,  gave  individual  clinics  appointment  scheduling  capabil¬ 
ity  to  ease  the  burden  on  the  crowded  centralized  scheduling  system.  The  “bugs”  are 
slowly  being  worked  out  of  the  system  and,  as  time  passes,  it  requires  less  of  her  time. 

The  factor  on  which  she  spends  the  majority  of  her  time  is  a  productivity  report 
she  is  attempting  to  get  accepted  as  a  monitoring  tool.  The  developed  report  satisfies  the 
major  information  needs  in  her  job — how  to  measure  output  of  individual  clinics  for  better 
civilian  and  military  personnel  staffing. 

She  described  the  mechanics  of  extracting  the  data  from  other  reports  and 
databases  in  order  to  generate  her  final  product,  which  is  presented  to  the  Chief  of 
Resource  Management  Division.  On  a  monthly  basis,  clinics  hand-prepare  a  310  Report 
which  identifies  by  health-care  provider  the  number  of  total  work  units  he/she  has  earned 
the  past  month.  The  monthly  work  unit  average  is  then  calculated  for  the  clinic.  It  is 
important  to  note  that  a  work  unit  depends  on  the  type  of  health-care  service  being 
rendered — it  may  be  x-rays  taken,  patients  seen,  pharmaceuticals  dispensed,  or  some  other 
dictated  method  from  HSC.  The  310  Report  is  then  forwarded  to  the  Resource  Manage¬ 
ment  Division. 

She  further  explained  that  administrative  personnel  in  her  division  enter  this 
work-center  data  into  a  database  going  back  two  years.  This  database  contains  a  summary 
of  the  310  Report  in  the  form  of  a  Running  Schedule  X  Report.  The  Running  Schedule  X 
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Report  maintains  by  clinic  a  monthly  running  total  of  work  units  earned,  staffing  strength, 
and  work  units  earned  by  personnel  not  part  of  the  paid  staff  (volunteers.  Red  Cross  per¬ 
sonnel,  etc.). 

She  explained  she  next  extracts  data  from  both  reports  to  make  her  Productivity 
Report  Her  report  takes  average  work  units  earned  by  each  clinic  for  the  month  and  the 
average  staffing  of  clinics  excluding  non-payroll  volunteer  work,  and  compares  these  two 
factors  with  the  number  of  staff  HSC  has  determined  will  be  assigned  to  the  clinic.  The 
final  product  is  input  to  a  Lotus  1-2-3  software  package  that  summarizes,  by  month,  aver¬ 
age  staffing  levels  and  work  units  performed.  This  information  is  used  primarily  as  a 
monitoring  tool  that  compares  clinic  output  with  staffing  levels.  With  this  information, 
resource  managers  can  look  at  a  particular  clinic  over  a  period  of  several  months  and  verify 
that  with  additional  staffing  a  clinic  has  provided  more  work  units,  as  would  be  expected. 
This  tool  can  also  identify  negative  trends,  such  as  additions  to  staffing  and  no  significant 
increase  in  work  units  provided  or  even  a  reverse  output  trend. 

Ultimately,  this  report  is  used  to  directly  affect  civilian  hiring  and  reallocation  of 
military  personnel.  Often  she  is  asked  to  analyze  the  impact  of  reducing  clinic  staffing  lev¬ 
els.  She  sees  this  Productivity  Report  as  an  essential  tool  in  performing  her  job. 

5.  Managerial  Position 

She  views  her  job  as  a  staff  officer,  providing  input  to  the  Chief  of  Resource 
Management  Division  on  any  aspect  of  the  hospital  that  is  required.  She  is  called  upon  to 
perform  any  catch-all  job  that  does  not  fall  within  other  job  descriptions  and  deals  with 
resource  management  monitoring.  Her  job  deals  with  administrative  issues  affecting  nurs¬ 
ing,  patient  care,  and  patient  complaints.  An  example  she  pointed  out  would  be  the 
investigation  of  whether  a  new  inpatient  ward  or  clinic  should  be  opened.  She  would 
assess  the  impact  this  venture  would  have  on  overall  goals  and  objectives  of  the  hospital. 


As  described  earlier,  she  needs  data  from  a  varied  number  of  Management 
Information  Systems  (MIS)  currently  in  operation.  She  works  predominantly  with  histori¬ 
cal  data  and  some  current  data  to  project  workload  trends  in  the  future.  The  data  she  does 
use  requires  a  great  deal  of  processing  by  her  staff  into  a  form  that  is  usable  for  presenta¬ 
tion  to  decision  makers. 

6.  Internal  and  External  Factors 

The  only  factor  she  wished  she  could  control  is  the  method  HSC  uses  to  dictate 
the  amount  of  staff  to  be  assigned  to  a  clinic.  She  explained  that  in  a  few  clinics,  the  num¬ 
ber  of  health-care  providers  authorized  is  based  on  an  uncontrollable  factor  such  as  the 
civilian  population  in  the  surrounding  geographical  area.  This  arbitrary  authorization  of 
staff  to  a  clinic  sometimes  frustrates  resource  managers  when  they  attempt  to  reallocate 
health-care  providers  in  contrast  to  HSC  guidance. 

7.  Monitoring  and  Building  Factors 

She  predominantly  is  concerned  with  monitoring  output  from  clinic  and  ward 
staffing  levels  and  reporting  trends  to  the  Chief  of  Resource  Management  Division.  She 
explained  this  area  of  her  job  is  most  important  for  her  success  or  failure  in  the  Resource 
Management  Division.  From  the  information  provided  through  her  Productivity  Report, 
the  Chief  of  Resource  Management  Division  can  make  educated  decisions  concerning 
staffing  levels  throughout  the  hospital. 

C.  SUMMARY  OF  INTERVIEW  WITH  THE  CHIEF  OF  PATIENT 

ADMINISTRATION  DIVISION 

The  Chief  of  Patient  Administration  Division  works  directly  for  the  Deputy 
Commander  for  Administration.  He  took  over  the  job  only  four  months  ago. 
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1.  Industry  Factors 

He  could  identify  one  factor  about  which  he  is  most  concerned  within  the 
Patient  Administration  Division.  His  work  center  is  responsible  for  all  inpatient  records 
and  birth  and  death  information.  The  accuracy  and  confidentiality  of  this  data  is  vitally 
important  to  his  job  success.  He  therefore  staffs  his  work  centers  accordingly.  He  assigns 
quality  personnel  to  the  record-keeping  work  centers  over  the  more  mundane  ones  such  as 
word  processing. 

2.  Competitive  Strategy  and  Industry  Position 

He  viewed  his  job  as  more  a  caretaker  than  a  strategic  planner.  He  felt  that  a 
mismanaged  Patient  Administration  Division  can  significantly  slow  a  hospital’s  internal 
functioning  as  well  as  destroy  its  credibility  with  erroneously  reported  births  and  deaths. 
For  this  reason,  an  officer  capable  of  dealing  with  all  aspects  of  administrative  reporting  is 
required  to  closely  supervise  accurate  administrative  documentation. 

He  pointed  out  that  one  of  his  informal  goals  in  the  next  12  months  was  to  get 
his  workcenter’s  staffing  level  back  to  a  level  he  feels  comfortable  with.  At  this  time,  he 
has  several  vacant  positions  in  the  medical  records  section,  and  if  these  positions  are  not 
filled  quickly  it  may  affect  the  accuracy  and  confidentiality  issue. 

3.  Environmental  Factors 

He  explained  that  fluctuating  patient  levels  had  the  most  significant  impact  on 
his  job.  When  patient  levels  increase  dramatically,  his  staff  is  flooded  with  Civilian  Health 
And  Medical  Program  of  the  Uniformed  Services  (CHAMPUS)  requests  and  associated 
paperwork.  SBHACH  has  approximately  125  beds  for  inpatients.  When  this  space 
approaches  full  capacity,  his  staff  has  difficulty  in  keeping  up  with  the  administrative 
paperwork  such  as  surgery  narratives,  check-in/check-out  functions,  birth/death  certifi- 
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cates,  and  workload  summaries  for  all  work  centers.  He  stated,  “If  the  hospital  closed 


down  today,  we  would  finally  finish  our  job  about  two  weeks  later.” 

4.  Temporal  Factors 

He  identified  two  temporal  factors  affecting  him  now:  the  two  Primary  Care  to 
Uniformed  Services  (PRIMUS)  clinics  being  opened  at  The  Presidio  of  Monterey  and 
Salinas,  California,  and  the  CHAMPUS  Reform  Initiative. 

With  the  opening  of  the  two  satellite  PRIMUS  clinics,  his  staff  will  provide 
administrative  support  by  maintaining  health  records  initiated  by  the  civilian  funded  pro¬ 
grams.  When  patients  are  treated  at  these  satellite  locations,  his  staff  will  provide  periodic 
audit  services  and  correct  administrative  defects  discovered. 

The  CHAMPUS  Reform  Initiative  is  a  program  sponsored  by  the  HSC  to  retard 
the  yearly  costs  of  CHAMPUS,  which  currently  are  rising  at  a  rate  of  25  percent  a  year.  In 
effect,  the  purpose  of  the  CHAMPUS  reform  initiative  is  to  identify  a  number  of  health¬ 
care  providers  outside  the  military  hospital  system  who  can  provide  medical  care  for  the 
overflow  of  patients  at  SBHACH.  Using  these  health-care  providers  under  contract  will 
cost  the  government  less  in  CHAMPUS  costs  than  the  current  method  of  using  outside 
medical  practitioners.  He  will  be  required  to  provide  administrative  support  to  the  team  that 
will  be  setting  up  the  new  CHAMPUS  system  in  the  surrounding  community. 

5.  Managerial  Position 

He  does  very  little  information  management  in  the  hospital.  He  identified  his 
work  center  as  a  source  of  one  feeder  report  which  resource  managers  use.  The  monthly 
Workload  Report  is  a  summary  of  data  obtained  from  the  AQCESS  MIS  and  provides  a 
breakout  by  clinic  and  health-care  provider  of  the  workload  accomplished  over  a  given 
period  of  time.  This  report  functions  as  a  monthly  database  and  is  forwarded  to  the 
Resource  Management  Division,  where  data  is  extracted  to  generate  a  number  of  reports  to 
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monitor  clinic  productivity.  A  spin-off  of  this  report  calculates  the  number  of  Medical  Care 
Composite  Units  (MCCUs)  the  hospital  has  unofficially  earned  for  resource  allocation. 
The  MCCU  estimation  is  used  by  administrators  to  monitor  the  individual  clinics. 

6.  Internal  and  External  Factors 

He  reiterated  that  he  is  affected  externally  by  the  patient  levels  and  cannot  react 
to  this  fluctuation  easily. 

7.  Monitoring  and  Building  Factors 

He  monitors  his  staffing  levels  very  closely.  He  noted  that  if  certain  key  posi¬ 
tions  remain  vacant  for  extended  periods,  he  will  assume  the  job  is  not  being  done  as  effi- 
ciently  as  possible  and  takes  appropriate  quality  assurance  action  to  inspect  output  and 
make  necessary  corrections. 

D.  SUMMARY  OF  INTERVIEW  WITH  THE  CHIEF  OF  PERSONNEL 

DIVISION 

The  Chief  of  Personnel  Division  works  directly  for  the  Deputy  Commander  of 
Administration.  He  has  been  in  the  current  job  for  over  a  year  and  moved  up  from  other 
assorted  administrative  jobs  in  the  hospital. 

1.  Industry  Factors 

He  identified  one  major  health-care  industry  factor  that  affected  his  division. 
He  pointed  out  that  the  hiring  of  civilian  personnel  was  always  at  the  forefront  of  his  atten¬ 
tion.  The  Department  of  Defense  (DOD)  hiring  freeze  especially  affects  the  hospital  in  the 
large  number  of  vacant  positions. 

2.  Competitive  Strategy  and  Industry  Position 

He  viewed  his  job  as  90  percent  caretaker  and  the  remainder  as  a  strategic  plan¬ 
ner.  He  described  his  job  as  maintaining  personnel  records  support  for  all  military  and 
civilian  personnel  working  within  the  hospital. 


The  military  personnel  have  their  records  maintained  on  a  local  MIS  called 
Standard  Installation  Divisional  Personnel  System  (SIDPERS),  which  feeds  the  Fort  Ord 
SIDPERS  database.  The  information  is  kept  on  over  15  fields  of  data  elements,  including 
rank,  social  security  number,  name,  date  of  birth,  and  other  miscellaneous  personal  infor¬ 
mation  that  would  be  kept  by  administrative  and  record-keeping  personnel. 

His  people  are  responsible  for  maintaining  the  accuracy  of  these  records,  mak¬ 
ing  changes  as  personal  information  changes  for  assigned  personnel,  and  adding  new 
arrivals  and  deleting  transfers.  Some  data  fields  are  protected,  such  as  the  grade  and  pay 
fields.  All  other  fields  may  be  updated  and  updates  are  then  sent  to  the  database  on  post. 
Any  pay  upgrades  are  hand-routed  to  the  database  on  post  and  the  changes  are  reflected  in  a 
short  time. 

He  uses  this  database  to  view  the  information  in  different  ways  to  answer 
queries  that  come  up  during  the  course  of  business.  A  sample  question  might  be  “How 
many  enlisted  troops  are  working  at  the  hospital  who  have  a  rank  over  E-5  and  are  single?” 
Although  SIDPERS  provides  an  ad  hoc  query  function  that  allows  users  to  view  the 
database,  it  is  limited  in  scope.  He  noted  that  questions  arise  that  are  answered  by 
manually  combining  both  SIDPERS  and  other  databases  and  hand-sorting  personnel 
records.  In  these  cases,  a  method  of  viewing  this  data  in  some  relational  format  would 
greatly  enhance  the  Personnel  Division.  He  noted  that  the  amount  of  time  spent  on  access¬ 
ing  the  database  was  70  percent  ad  hoc  and  30  percent  for  routine  queries. 

One  of  the  short-term  goals  on  which  he  is  working  is  the  maintenance  of  mili¬ 
tary  health-care  providers’  qualification  records  for  going  into  combat  with  the  rapid 
deployable  forces.  Health-care  providers  (corpsmen,  doctors,  and  nurses)  are  assigned  to 
deployable  units  and  qualifications  must  be  met  in  order  for  them  to  go  into  combat  with  the 
ground  units  when  they  deploy.  The  qualifications  record-keeping  is  a  major  task  for  him 
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and  his  staff.  Some  of  the  data  fields  are  maintained  by  SIDPERS  and  some  are  maintained 
manually.  He  would  like  to  implement  some  system  that  could  use  SIDPERS  data  ele¬ 
ments  along  with  others  in  a  relational  database.  It  is  vitally  important  for  health-care 
providers  to  have  up-to-date  qualifications  in  order  to  go  into  potential  combat  situations. 
The  system  he  envisions  would  automatically  flag  personnel  whose  qualifications  have 
expired  or  will  expire  prior  to  the  next  scheduled  training  cycle. 

An  important  part  of  his  job  is  maintaining  staff  levels  of  both  military  and 
civilian  personnel.  The  hospital  is  authorized  only  so  many  military  health-care  providers, 
and  the  remaining  positions  are  filled  by  civilian  employees.  In  the  event  of  budget  cuts,  it 
is  necessary  to  reduce  the  number  of  civilians  and/or  freeze  the  hiring  rate.  When  this  hap¬ 
pens,  the  remaining  military  must  work  longer  shifts  and  military  personnel  assigned 
directly  to  ground  units  must  be  pulled  back  to  the  hospital  to  augment  the  staff  until  reliu 
in  the  form  of  reduced  workload  or  civilian  hires  is  accomplished.  As  shortages  exist 
within  the  hospital  in  civilian  employees,  a  committee  consisting  of  managers  meets  as 
needed  to  decide  on  the  hiring  for  departments  that  are  understaffed.  A  critical  information 
requirement  is  some  sort  of  quantitative  tool  to  determine  which  departments  are  in  the 
greatest  need  for  new  employees. 

3.  Temporal  Factors 

The  only  temporal  problem  he  sees  at  this  time  is  the  budget  situation.  The  state 
of  the  budget  has  caused  a  hiring  freeze  on  civilian  employees.  At  this  time,  military  per¬ 
sonnel  have  been  jockeyed  around  and  shift  hours  have  been  expanded  to  handle  this  crisis. 
There  is  not  much  anyone  at  the  hospital  can  do  to  alleviate  this,  but  they  can  ensure  that 
military  health-care  providers  moved  within  the  hospital  or  added  from  the  outside  as  aug- 
mentees  are  done  so  in  an  intelligent  manner.  In  other  words,  clinics  and  wards  that  need 


people  most  get  these  people,  and  the  impact  of  reassigning  an  individual  within  the  hospi¬ 
tal  is  investigated  fully. 

4.  Managerial  Position 

He  functions  as  a  staff  officer  who  maintains  up-to-date  information  on  military 
and  civilian  personnel.  He  accesses  two  MIS  to  maintain  records  on  the  hospital  work 
force.  On  the  military  side,  he  is  the  troop  commander  responsible  for  maintaining  good 
order  and  discipline  as  well  as  promotions.  For  the  civilian  workforce,  he  is  responsible 
for  recruiting  and  hiring  when  the  need  arises.  The  Uniform  Chart  of  Accounts  Perfor¬ 
mance  Expense  Reports  System  (UCAPERS)  provides  information  on  civilian  health-care 
providers,  and  the  SIDPERS  system  maintains  files  on  military  personnel. 

If  the  military  work  force  is  experiencing  a  shortage,  he  is  required  to  deal  with 
the  next  level  of  command  to  get  new  personnel  assigned  to  SBHACH.  If  it  is  the  civilian 
work  force  that  is  short,  the  committee  decides  on  what  job  description  is  required  and  he  is 
responsible  for  advertising  and  hiring. 

5.  Internal  and  External  Factors 

The  dominant  factor  in  his  job  is  to  ensure  that  the  work  force  is  maintained  at 
the  level  necessary  to  provide  competent  health  care  to  patients.  Even  if  this  goal  is  to  be 
performed  at  the  expense  of  administrative  functions,  it  must  be  done.  Since  his  division  is 
primarily  administrative  in  nature,  he  is  prepared  to  sacrifice  human  resources  for  the  more 
important  clinics. 

6.  Monitoring  and  Building  Factors 

In  order  to  answer  questions  concerning  staffing  levels  and  hiring  rates,  he 
must  do  a  great  deal  of  ad  hoc  questioning  of  his  staff.  The  information  he  requires  is  not 
always  readily  available  and  requires  him  to  search  out  the  necessary  data  to  make 
decisions. 
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He  always  monitors  the  unit  discipline  and  reassignment  of  personnel  within  the 
hospital.  He  needs  to  continuously  know  any  changes  to  staffing  levels  in  order  to  keep 
the  commander  apprised  of  changes  that  will  affect  patient  treatment. 

E.  SUMMARY  OF  INTERVIEW  WITH  THE  DEPUTY  COMMANDER  FOR 

ADMINISTRATION 

The  Deputy  Commander  for  Administration  at  SBHACH  is  responsible  for  all  ad¬ 
ministrative  matters  within  the  hospital  and  reports  directly  to  the  Hospital  Commander. 
Prior  to  taking  this  post  at  Fort  Ord,  he  served  in  a  smaller  hospital  overseas,  where  he 
performed  a  similar  job. 

1.  Industry  Factors 

The  information  area  he  feels  the  hospital  needs  the  most  is  timely,  accurate 
information.  He  requires  information  on  earned  MCCUs  and  compares  this  figure  to  out¬ 
put  spent  by  the  individual  clinics  and  wards.  Areas  that  get  the  hospital  in  trouble  are 
spending  more  on  output  then  is  earned  through  health-care  services  provided  and  the  slow 
method  of  calculating  MCCUs  earned  by  the  hospital. 

2.  Competitive  Strategy  and  Industry  Position 

He  described  his  job  as  being  both  a  monitor  and  strategic  planner,  but  more 
towards  monitoring  tasks.  He  functions  as  a  staff  officer  to  the  Hospital  Commander  and 
provides  the  commander  with  information  on  administrative  functions. 

He  identified  two  primary  goals  he  is  attempting  to  accomplish  within  the  next 
12  months.  He  is  trying  to  market  the  nursing  positions  at  the  hospital  and  increase  the 
productivity  of  the  individual  departments  through  education  and  training. 

There  is  a  civilian  nursing  shortage  at  SBHACH.  The  hospital  is  authorized  to 
pay  civilian  nurses  at  a  given  rate,  but  the  surrounding  community  is  paying  their  nursing 
staff  at  a  much  higher  rate.  Therefore,  it  is  difficult  to  attract  nurses  to  SBHACH.  The 


method  he  is  using  to  solve  this  problem  is  to  increase  the  productivity  of  the  hospital,  earn 
more  funding  for  the  hospital  through  this  increased  productivity,  and  take  the  funding  and 
augment  salaries  of  the  civilian  nursing  staff  in  order  to  attract  and  maintain  needed  nurses. 
Normally,  excess  funds  would  be  turned  into  HSC  for  reallocation.  However,  he  has 
struck  a  deal  that  allows  him  to  use  these  funds  for  civilian  nursing  and  some  capital 
equipment 

3.  Environmental  Factors 

He  is  concerned  with  the  effect  the  two  PRIMUS  clinics  that  are  being  opened 
near  Fort  Ord  will  have  on  the  hospital.  The  PRIMUS  clinics  were  designed  to  provide 
health  care  to  active  duty,  retired,  and  dependent  personnel  as  an  alternative  to  the  medical 
treatment  also  provided  at  SBHACH.  The  medical  care  is  provided  by  mostly  civilian  per¬ 
sonnel  under  contract  and  covers  small  injuries,  common  illnesses,  and  general  medical 
problems.  Although  the  two  PRIMUS  clinics  will  duplicate  a  percentage  of  medical  care 
that  is  already  provided  at  SBHACH,  there  are  certain  medical  services  not  provided. 
SBHACH  will  still  offer  all  medical  services,  but  the  PRIMUS  clinics  will  take  some  of  the 
workload  from  the  hospital  and  give  additional  medical  care  to  the  surrounding  military 
community.  The  PRIMUS  clinics  can  have  three  effects  on  the  hospital:  They  may  attract 
patients  away  from  the  hospital  and  cause  the  overall  hospital  productivity  to  drop,  they 
may  increase  the  amount  of  patients  treated  through  patient  referrals,  or  the  patient  levels 
may  remain  the  same. 

Another  identified  environmental  factor  that  affects  the  hospital  is  the  lack  of 
control  over  military  construction.  Military  construction  is  provided  locally  from  the  base 
and  the  hospital  has  little  control  over  it  from  the  standpoint  of  pushing  projects  through  to 
completion  that  they  deem  as  the  most  important.  He  cannot  contract  out  specific  projects 
to  be  completed  and  must  rely  on  the  post  to  provide  this  support. 


4.  Temporal  Factors 

He  identified  a  number  of  temporal  factors  with  which  he  is  dealing  at 
SBHACH.  The  most  important  factors  are  how  the  PRIMUS  clinics  and  the  CHAMPUS 
reform  initiative  in  combination  will  affect  the  workload  at  the  hospital.  Hospital  adminis¬ 
trators  are  waiting  to  see  how  the  workload  will  fluctuate  before  taking  action  to  address 
these  factors.  An  action  officer  has  been  assigned  to  monitor  this  factor. 

5.  Managerial  Position 

He  described  his  managerial  position  as  one  of  evaluating  performance.  He 
constantly  monitors  the  levels  of  clinic  productivity,  patient  levels,  and  consumption  of 
resources  in  treating  patients.  He  gets  most  of  the  information  he  needs  from  the  Produc¬ 
tivity  Report  supplied  by  the  Resource  Management  Division  that  identifies  a  variety  of 
information,  including  the  capacity  of  each  ward  and  the  status  of  the  nursing  staff. 

He  relies  heavily  on  the  earned  value  of  MCCUs  throughout  the  hospital.  He 
needs  to  know  the  cunrent  earned  value  of  the  hospital’s  MCCUs  in  relation  to  the  estab¬ 
lished  goal  set  by  his  office.  Unfortunately,  the  exact  number  of  MCCUs  earned  to  date  is 
accurate  to  only  ten  days  prior  to  the  present  date.  If  he  wants  the  exact  number  of  MCCUs 
earned  to  date,  it  takes  about  ten  days  to  compile  this  figure  for  use. 

6.  Internal  and  External  Factors 

One  of  the  areas  that  affects  his  job  most  that  he  is  unable  to  control  is  the  cyclic 
nursing  problem.  As  nursing  levels  drop  due  to  fewer  nurses  hired  at  the  hospital,  patient 
levels  drop  because  there  are  not  enough  nurses  available  to  staff  hospital  wards,  and  as  a 
result  the  hospital’s  productivity  declines.  Higher  headquarters  sees  this  decline  in 
productivity,  determines  that  the  hospital  has  excess  capacity,  lowers  the  amount  of  nurses 
allowed  to  be  hired,  and  the  cycle  then  repeats. 
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7.  Monitoring  and  Building  Factors 


He  stated  that  his  job  is  primarily  a  job  of  monitoring  the  input,  output,  and 
budget  expenditures  of  the  hospital.  He  is  concerned  with  significant  budget  decisions  and 
patient  levels.  He  uses  the  MCCU  method  as  a  monitoring  tool  to  measure  the  success  of  a 
specific  ward  within  the  hospital.  The  goal  for  the  hospital  is  to  earn  780  MCCUs  per  day 
and  spend  $24  worth  of  resources  on  each  MCCU  earned.  Currently,  the  hospital  is  earn¬ 
ing  840  MCCUs  per  day,  and  spending  $18  worth  of  resources  for  each  MCCU  earned. 

The  profit  the  hospital  is  generating  is  used  to  provide  salary  incentives  to  attract 
and  maintain  an  appropriate  nursing  staff  level  within  the  hospital  as  well  as  to  purchase 
equipment  that  is  at  the  forefront  of  certain  medical  technologies  to  provide  the  latest  health¬ 
care  possible. 

He  maintains  a  monthly  statistic  report  that  follows  each  clinic  and  provides  a 
breakdown  of  current  monthly  admissions,  average  daily  admissions,  and  an  optimal 
admission  goal  established  for  each  clinic  based  on  spending  $20  on  resources  per  MCCU. 
With  this  report,  he  can  easily  see  which  clinics  are  ahead  or  behind  their  optimal  goals  and 
take  corrective  action.  Unfortunately,  this  report  is  only  a  snapshot  at  one  particular  time 
during  the  month  and  the  information  becomes  dated  quickly.  There  is  a  need  for  a  report 
that  is  on-line  and  provides  this  same  information  in  order  to  make  educated  decisions. 

F.  SUMMARY  OF  INTERVIEW  WITH  THE  DEPUTY  COMMANDER  FOR 

CLINICAL  SERVICES 

The  Deputy  Commander  for  Clinical  Services  reports  directly  to  the  Hospital  Com¬ 
mander  on  the  operational  function  and  performance  of  the  clinics  and  wards. 

1.  Industry  Factors 

He  is  most  concerned  with  maintaining  the  working  level  of  the  hospital  and 
staff  up  to  the  bed  capacity  to  ensure  full  usage  of  medical  treatment  facilities.  Maintaining 
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the  inpatient  levels  at  or  near  the  hospital’s  bed  capacity  ensures  proper  training  of  person¬ 
nel  assigned  in  resident  programs  and  provides  the  surrounding  community  with  adequate 
health-care  services. 

2.  Competitive  Strategy  and  Industry  Position 

He  functions  as  a  caretaker  to  report  on  the  status  of  the  clinics  and  wards 
throughout  the  hospital  He  is  also  responsible  for  maintaining  proper  staffing  levels  in  the 
clinics  and  wards.  Although  personnel  are  trained  in  specific  health-care  areas  such  as 
orthopedics,  nursing,  pharmaceutical  techniques,  etc.,  he  still  has  the  ability  to  move  per¬ 
sonnel  around  to  the  extent  of  filling  gaps  where  needed  and  to  provide  proper  training  to 
health-care  providers. 

3.  Environmental  Factors 

The  only  environmental  factor  he  could  point  out  was  the  nursing  shortage  that 
is  affecting  the  hospital.  This  problem  is  well  documented  in  previous  interviews. 

4.  Temporal  Factors 

Also  noted  in  previous  interviews  is  the  effect  the  PRIMUS  clinics  will  have  on 
the  patient  levels  of  the  hospital.  He  described  this  factor  as  important  because  the 
PRIMUS  clinics  may  take  away  business  as  well  as  refer  patients  in  large  amounts. 

5.  Managerial  Position 

He  uses  three  reports  to  monitor  the  individual  clinics  within  the  hospital:  the 
Nursing  Report,  the  Officer  of  the  Day  Report,  and  the  Administrative  Officer  of  the  Day 
Report.  He  stated  that  he  found  everything  he  needed  in  these  reports  to  provide  necessary 
direction  to  the  wards  and  clinics. 

The  Nursing  Report  provides  information  about  inpatients  in  the  form  of  identi¬ 
fying  the  most  severe  cases  and  those  cases  that  may  have  a  command  interest.  The  report 
is  broken  down  by  ward  and  provides  the  number  of  patients  in  each  ward,  the  capacity  of 
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the  ward,  and  certain  traits  such  as  patient  categories,  potential  discharges,  and  age  traits. 
This  report  spans  the  past  24-hour  period. 


The  Officer  of  the  Day  Report  provides  the  number  of  admissions  for  a  given 
24-hour  period,  serious  illness  and  deaths,  command  interest  cases,  and  training  accident 
cases.  This  data  is  used  to  monitor  the  status  on  patients  and  provide  feedback  to  health¬ 
care  administrators  on  selected  patients. 

The  last  report.  The  Administrative  Officer  of  the  Day  Report,  is  used  to  pro¬ 
vide  information  on  such  items  as  food  services  and  hospital  security.  These  items  are  not 
as  critical  in  nature  as  the  Officer  of  the  Day  Report,  yet  necessary  to  monitor  the  hospital. 

6.  Monitoring  and  Building  Factors 

He  primarily  monitors  the  patient  satisfaction  throughout  the  hospital  and  the 
numbers  of  patients  in  the  hospital.  If  patient  satisfaction  is  not  adequate  in  a  certain  clinic 
and  there  is  a  trend  developing,  he  takes  the  action  necessary  to  set  the  clinic  back  on  the 
right  track. 

G.  SUMMARY  OF  INTERVIEW  WITH  THE  COMMANDING  OFFICER, 

SBHACH 

The  Commanding  Officer  of  SBHACH  has  filled  this  position  for  at  least  two  years. 
Prior  to  this  position,  he  served  at  SBHACH  in  other  job  billets,  including  the  Deputy 
Commander  for  Clinical  Services,  before  stepping  up  as  the  Commanding  Officer  of 
SBHACH. 

1.  Industry  Factors 

He  explained  that  his  job  was  no  different  than  the  civilian  counterpart  to  his 
job.  He  requires  fast,  accurate  information  from  all  parts  of  the  hospital  about  the  entire 
organization.  He  depends  on  his  staff  to  keep  him  informed  on  any  important  detail  that 
may  affect  the  reputation  of  the  hospital. 
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Two  other  important  industry  factors  on  which  he  needs  information  arc  what  is 
happening  in  the  department  of  surgery  and  how  much  unused  capacity  in  the  form  of 
unused  bed  space  exists  daily.  Every  morning  he  conducts  a  morning  status  meeting  that 
provides  him  with  information  on  what  type  of  surgery  will  be  performed  for  that  day,  how 
it  went  the  previous  day,  and  the  unused  bed  space  over  the  past  24-hour  period. 

2.  Competitive  Strategy  And  Industry  Position 

The  Commanding  Officer  pointed  out  that  his  major  goals  in  this  area  were 
monitoring  funding  constraints  and  preparing  for  anticipated  needs.  He  talked  about  how 
the  lack  of  funds  this  year  has  made  it  difficult  for  the  hospital  to  hire  needed  civilian 
health-care  providers,  specifically  nurses.  This  has  caused  him  to  approach  the  nursing 
issue  in  a  unique  manner. 

The  resource  managers  at  SBHACH  have  increased  the  productivity  of  the 
clinics  in  order  to  earn  excess  funds  which  can  be  spent  on  attracting  civilian  nurses  at  an 
increased  pay  rate  than  what  they  are  authorized  to  pay  now.  The  pay  rate  for  civilian 
nurses  at  SBHACH  is  much  lower  than  the  surrounding  community  and  it  is  difficult  to 
attract  good  nurses  to  the  hospital.  By  saving  this  money  through  increased  productivity, 
they  can  now  establish  a  salary  to  compete  with  the  outside  community. 

He  went  on  to  point  out  that  the  hospital  plans  for  anticipated  needs  due  to 
changes  in  technology.  They  must  be  able  to  procure  the  necessary  personnel  and  machin¬ 
ery  to  keep  the  hospital  in  the  position  of  a  competent  provider  of  health-care  services  on 
the  leading  edge  of  recent  medical  advances. 

3.  Environmental  Factors 

He  presented  three  environmental  factors  that  affect  the  hospital:  the  budgetary 
constraints  requiring  the  hospital  to  operate  at  a  profit,  fluctuating  patient  levels,  and 
changes  in  training  intensity  levels  at  Fort  Ord. 
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Budgetary  constraints  require  SBHACH  to  operate  at  a  profit.  The  hospital 
must  provide  adequate  health-care  services  and  yet  not  overspend  its  earned  allotment  of 
funds.  As  Chapter  III  describes,  the  method  of  reimbursement  for  health-care  services 
provided  is  the  Medical  Care  Composite  Unit  (MCCU).  He  requires  an  accurate  approxi¬ 
mation  of  what  the  hospital’s  current  spending  level  is  in  order  to  make  decisions  on  pur¬ 
chasing  capital  equipment  and  hiring  civilian  employees.  Unfortunately,  the  method  for 
reporting  this  information  is  slow,  taking  up  to  ten  days  at  a  time  to  provide  managers  with 
an  accurate  estimate  of  MCCUs  earned  to  date. 

The  Hospital  Commander  explained  that  fluctuating  patient  levels  affected  the 
hospital  in  terms  of  earning  MCCUs.  Simply  put,  if  patient  levels  drop  significantly,  he 
can  expect  a  corresponding  drop  in  the  MCCU  rate  earned  as  well.  If  this  level  persists,  he 
must  investigate  to  find  out  why  this  is  happening  and  take  appropriate  action  if  possible. 

The  last  environmental  factor  presented  was  the  effect  changing  levels  of  train¬ 
ing  intensity  at  Fort  Qrd  had  on  the  hospital.  As  training  by  ground  units  intensifies,  the 
injury  rate  of  personnel  involved  increases.  A  majority  of  these  injuries  are  orthopedic  in 
nature  and  require  the  services  of  skilled  orthopedic  personnel.  To  augment  his  orthopedic 
clinic,  he  has  thought  about  implementing  a  sports  physician  to  handle  those  injuries  that 
are  frequently  seen  from  training  requirements. 

4.  Temporal  Factors 

He  pointed  out  two  temporal  factors  affecting  the  administration  of  the  hospital. 
He  is  concerned  with  the  effects  the  CHAMPUS  reform  initiative  and  the  PRIMUS  clinics 
will  have  on  the  patient  levels  at  the  hospital.  He  has  appointed  a  project  officer  to  assess 
the  impact  these  two  variables  will  have  on  patient  levels  at  the  hospital. 

The  major  impact  of  opening  two  clinics  in  the  surrounding  area  is  that  they  will 
attract  some  of  SBHACH’s  clientele  and  reduce  the  MCCU  earnings.  But  what  may  also 
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happen  is  that  a  ghost  population  (people  who  don’t  normally  go  to  the  hospital  because  it 
is  difficult  and  time  consuming)  may  fill  in  the  void  and  take  up  some  of  the  capacity  of  the 
PRIMUS  clinics  and  fill  in  the  vacated  capacity  at  SBHACH.  This  situation  may  go  either 
way  and  is  a  major  concern  of  the  Hospital  Commander. 

5.  Managerial  Position 

In  order  to  perform  his  job,  he  depends  on  his  staff  to  provide  him  with  accu¬ 
rate  and  timely  reports.  He  depends  on  data  provided  by  the  oral  morning  reports,  emer¬ 
gency  room  report,  surgical  reports,  and  the  scrubbed  data  from  the  different  MIS  in  the 
hospital. 

Another  key  factor  he  monitors  is  the  laboratory  trend  analysis.  If  the  lab  is 
finding  a  great  deal  of  a  certain  amount  of  disease  or  sees  a  trend  developing,  the  hospital 
staff  must  initiate  action  to  determine  if  an  outbreak  or  reoccurrence  of  a  disease  or  epi¬ 
demic  is  happening. 

6.  Internal  and  External  Factors 

SBHACH  has  been  successful  in  cutting  back  on  resources  spent  on  supplies. 
The  Hospital  Commander  asked  for  a  22  percent  reduction  across  the  board  and  the  wards 
and  clinics  have  complied  with  this  request  The  program  to  drive  budget  cuts  was  primar¬ 
ily  an  educational  trend.  Under  his  guidance,  the  staff  educated  those  personnel  directly 
involved  in  keeping  fiscal  records  at  the  department  level.  In  addition,  personnel  receive  an 
indoctrination  lesson  on  the  goal  of  the  hospital  to  reduce  expenditures,  increase  productiv¬ 
ity,  and,  as  a  result,  earn  more  MCCUs. 

Another  external  factor  that  was  already  pointed  out  was  the  nursing  shortage 
SBHACH  was  experiencing.  The  commander  watches  the  hiring  trend  closely  to  ensure 
that  an  appropriate  nursing  staff  level  is  maintained. 
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7 .  Monitoring  And  Building  Factors 


Quality  of  care  and  productivity  are  the  key  areas  he  monitors.  He  monitors  the 
quality  of  care  by  the  number  of  complaints  he  receives  from  patients  about  a  particular 
department.  Of  course  there  will  always  be  complaints,  but  if  he  sees  a  trend  developing, 
he  takes  action  to  find  out  what  is  happening  and  whether  it  can  be  corrected. 

He  monitors  productivity  by  reviewing  a  monthly  Productivity  Report  that 
matches  the  number  of  MCCUs  earned  by  a  department  as  compared  to  their  optimal  goal 
he  has  established.  Again,  if  negative  trends  develop,  he  will  investigate  the  cause  and  take 
corrective  action  if  possible. 
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APPENDIX  D 


INTERVIEW  OF  MANAGEMENT  INFORMATION  SYSTEMS  PERSONNEL 

A.  DESCRIPTION 

This  appendix  summarizes  several  interviews  conducted  with  personnel  responsible 
for  maintenance  and  upkeep  of  Management  Information  Systems  (MIS)  at  Silas  B.  Hays 
Army  Community  Hospital  (SBHACH).  This  appendix  describes  system  details  of  stand¬ 
alone  MIS  providing  information  support  at  SBHACH.  The  information  gained  was  used 
in  determining  resource  usage  of  each  MIS  and  to  develop  an  understanding  of  what  data  is 
provided  by  each  MIS.  Names  of  the  personnel  assigned  these  billets  have  been  omitted 
though  there  is  nothing  inappropriate  in  any  of  the  interviews. 

B .  SUMMARY  OF  INTERVIEW  WITH  SBHACH  INFORMATION 

MANAGEMENT  DIVISION  PERSONNEL 

The  two  civilian  employees  working  in  the  Information  Management  Division  are 
tasked  with  performing  maintenance  on  the  Automated  Quality  of  Care  Evaluation  Support 
System  (AQCESS)  Management  Information  System. 

They  started  the  interview  by  pointing  out  that  the  AQCESS  MIS  is  a  relatively  recent 
addition  to  the  hospital  and,  having  just  been  implemented  at  the  first  of  the  year  (1988), 
the  “bugs”  are  still  being  worked  out  of  it.  The  AQCESS  system  runs  on  a  DEC  1 184 
computer  and  provides  information  to  all  clinics  about  patients  and  health-care  providers. 
Each  clinic  is  provided  with  a  separate  terminal  accessing  the  DEC  1 184  mainframe.  The 
system  provides  quantitative  information  about  the  health-care  services  provided  by  health¬ 
care  providers  and  the  inpatients  receiving  these  services  at  SBHACH. 
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The  AQCESS  system  has  three  modules:  Appointment  Scheduling,  Quality 
Assurance,  and  Patient  Data.  Appointment  Scheduling  is  a  decentralized  appointment 
scheduling  system  that  is  slowly  replacing  the  existing  centralized  appointment  scheduling 
system  in  the  hospital.  They  went  on  to  explain  that  the  appointment  scheduling  module 
allows  the  clinics  to  schedule  their  own  appointments,  schedule  appointment  referrals  to 
other  clinics,  record  appointments  kept,  record  walk-ins,  and  provide  print-outs  to  clinics 
regarding  future  and  past  schedules.  This  module  offers  a  number  of  views  of  data  and 
may  be  broken  down  by  patient,  clinic,  or  health-care  provider  over  varied  time  periods. 
They  also  noted  that  statistical  information  is  provided  by  this  module  which  is  helpful  in 
determining  clinic  and  health  care  provider  workload  levels. 

Quality  Assurance  is  used  to  provide  profile,  monitoring,  and  general  quality 
assurance  reports.  The  profile  reports  give  specific  information  on  health-care  providers. 
The  information  provided  includes  education  history,  personal  and  professional  credentials, 
and  credential  renewal  lists.  Also  provided  are  historical  listings  of  specific  patients  and 
medical  cases  the  health-care  provider  has  treated. 

Monitoring  reports  are  provided  on  both  clinic  and  health-care  providers.  A  general 
list  of  the  types  of  health  care  provided,  such  as  surgery,  physical  therapy,  etc.,  is  provided 
by  clinic  and  identifies  patients  treated.  Another  important  monitoring  tool  identifies  by 
patient  name  if  a  specific  health-care  provider  is  delinquent  in  updating  medical  records. 

The  last  reports  provided  by  Quality  Assurance  are  general  quality  assurance  reports. 
These  reports  summarize  important  data  such  as  blood  use,  patient  deaths,  and  readmission 
of  patients. 

The  third  AQCESS  module  is  Patient  Data.  This  module  provides  a  comprehensive 
record  of  inpatient  data  throughout  the  hospital  wards.  The  data  is  a  conglomeration  of 
necessary  information  about  inpatients  and  is  used  by  the  Patient  Administration  Division. 
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The  AQCESS  system  provides  both  routine  and  ad  hoc  reports.  Some  reports  are 
provided  every  24-hour  period;  specifically,  the  clinic  schedules  for  the  next  day  are  j 

routinely  provided  to  all  clinics.  A  smaller  number  of  reports  are  requested  irregularly 
whenever  specific  information  is  required  by  resource  managers. 

C.  SUMMARY  OF  INTERVIEW  WITH  RESOURCE  MANAGEMENT  1 

DIVISION  PERSONNEL 

The  two  individuals  interviewed  are  assigned  to  the  Resource  Management  Division 
and  are  tasked  with  extracting  needed  information  from  the  Uniform  Chart  of  Accounts  I 

Performance  Expense  Reports  (UCAPERS)  Management  Information  System. 

They  explained  that  the  purpose  of  the  UCAPERS  system  was  to  collect  and  report 
on  two  Uniform  Chart  of  Accounts  data  elements.  The  Uniform  Chart  of  Accounts  is  a  I 

uniform  accounting  procedure  established  in  1979.  This  procedure  makes  all  military 
hospital  commands  report  on  three  types  of  accounting  data  in  a  consistent  and  uniform 
manner.  The  three  types  of  data  reported  quarterly  to  higher  commands  are  expenses, 
personnel  usage  data,  and  workload  statistics.  The  UCAPERS  system  reports  personnel 
expense  and  usage  data. 

The  system  records  work  performed  by  civilian  and  military  health-care  providers, 
stores  this  data,  and  submits  the  data  to  Health  Services  Command  (HSC)  in  a  form  by 
which  HSC  can  provide  reimbursement  of  funds  to  SBHACH  for  health-care  services 
provided. 

The  current  system  of  reporting  to  DOD  the  amount  of  health-care  services  provided 
by  the  MTF  is  based  on  a  unit  called  a  Medical  Care  Composite  Unit  (MCCU).  When 
health-care  providers  (doctors,  nurses,  lab  technicians,...)  provide  services  to  patients  in 
the  form  of  consults,  surgery,  pharmaceutical  prescriptions,  bed  space,  radiology,  and 
other  varied  services,  the  MTF  is  credited  with  MCCUs  depending  on  the  type  of  service. 
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For  example,  an  outpatient  visit  is  worth  0.3  MCCUs,  a  live  birth  is  valued  at  10  MCCUs, 
and  admission  as  an  inpatient  is  worth  10  MCCUs  the  first  day  and  1  MCCU  every  day 
there  after.  All  health-care  services  provided  are  input  daily  by  data-entry  clerks  and 
maintained  on  a  computer  system  called  UCAPERS.  The  information  is  updated  daily,  and 
weekly  a  tape  is  run  summarizing  all  health-care  services  provided  by  the  hospital.  A  copy 
of  the  tape  is  sent  to  a  DOD-run  facility  where  the  data  is  calculated  into  MCCUs.  These 
MCCUs  are  used  by  DOD  quarterly  to  provide  monetary  funding  to  SBHACH  in 
reimbursement  for  health-care  services  provided  at  the  hospital.  A  hard-copy  report  is 
forwarded  to  the  hospital  one  month  after  the  quarter  has  expired  summarizing  the  MCCUs 
earned  for  the  previous  quarter. 

The  system  runs  on  Datapoint  hardware  connected  on  an  Attached  Resource 
Computer  (ARC)  network  of  microcomputers  throughout  the  hospital. 

The  importance  of  this  MIS  is  that  it  is  the  basis  for  which  output  in  the  form  of 
health-care  services  provided  is  related  to  input  in  the  form  of  budgetary  allocation. 

D .  SUMMARY  OF  INTERVIEW  WITH  THE  NON-COMMISSIONED 

OFFICER  IN  CHARGE  OF  THE  PERSONNEL  DIVISION 

The  Non-Commissioned  Officer  in  Charge  of  the  Personnel  Division  is  tasked  with 
maintaining  the  Standard  Installation  Divisional  Personnel  System  (SIDPERS) 
Management  Information  System 

He  explained  that  the  SIDPERS  MIS  is  a  personnel  information  system  keeping 
records  on  all  assigned  military  personnel  at  the  hospital.  It  is  a  personal  computer  system 
made  by  Burroughs  that  is  deployable  to  remote  sights. 

SIDPERS  maintains  records  of  military  personnel  assigned  to  SBHACH  on  a  hard 
disk  internal  to  the  computer.  The  data  fields  contain  standard  data  on  each  soldier  as  well 
as  detailed  information  on  education,  training,  sex,  religion,  next  of  kin,  etc.,  that  is 


necessary  to  the  smooth  function  of  his  organization.  As  information  on  a  soldier  changes, 
or  as  personnel  are  deleted  or  transferred,  the  database  is  updated  to  reflect  the  correct 
information. 

Every  working  day,  the  changes  occurring  over  the  past  day  are  copied  onto  a  floppy 
disk  and  hand-carried  to  the  SIDPERS  on  post  at  Fort  Ord  that  maintains  the  database  post¬ 
wide. 

SIDPERS  software  allows  users  to  view  the  database  in  different  manners.  It 
possesses  the  capabilities  of  a  relational  database  that  is  menu  driven  to  provide  quick 
access  to  data  that  satisfies  some  ad  hoc  queries.  In  addition  to  this  function,  SIDPERS 
also  provides  word-processing  capabilities. 

He  explained  that  although  the  system  provides  excellent  relational  database 
capabilities,  it  still  does  not  satisfy  all  information  requirements  his  division  is  tasked  with 
providing.  He  explained  that  he  cannot  add  data  fields  to  the  database  of  SIDPERS. 
Without  this  capability,  he  often  must  use  SIDPERS  data  with  other  databases  and 
manually  sift  through  records  to  obtain  a  desired  view  of  data.  Fortunately,  this  is  the  only 
limitation  he  could  point  out  about  the  SIDPERS  system. 
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APPENDIX  E 

DECISION  SUPPORT  SYSTEM  LEVELED  DATA  FLOW  DIAGRAM 


This  appendix  contains  the  leveled  data  flow  diagram  from  the  context  diagram  flevel 
0)  and  leveled  to  the  functional  primitive.  Each  bubble  represents  a  process,  with  the 
lowest-level  processes,  functional  primitives,  making  up  the  building  blocks  of  the  context 
diagram  [Page- Jones  80].  Functional  primitives  cannot  be  further  broken  down  into  lower- 
level  processes.  Note  that  bubble  0  is  broken  down  to  1.0,  2.0,  and  3.0.  Bubble  3,0  is 
then  broken  down  to  3.1,  3.2,  3.3,  etc.,  until  further  leveling  is  not  possible. 


Professional 


#  of  Admissions 


Report  L_#  of  phone  consults 


#  of  Inpatients 


Nursing 

Report 


4  of  live  births 


User  Inputs 


of  outpatient  visits 


of  Inpatient  visits 


Resource 


Management 


Analysis 


Productivity 


Analysis 


Schedule 


Report 


Monthly  work 


units  earned 


Average  monthly 


health-care  providers 


Level  0  Data  Flow  Diagram  Context  Diagram 


Level  2  Data  Flow  Diagram 

(from  bubble  3.0) 


119 


APPENDIX  F 


DECISION  SUPPORT  SYSTEM  MINI-SPECIFICATION 
DESCRIPTION 

Contained  in  this  appendix  is  a  statement  that  governs  the  transformation  of  input  data 

flow(s)  into  output  data  flow(s)  for  each  functional  primitive  in  the  data  flow  diagram. 

1.0  SET  UP  MCCU  DATABASES 

For  each  24-hour  period  at  hospital,  do  the  following: 

1  Get  NUMBER  OF  ADMISSIONS 

2  Get  NUMBER  OF  PHONE  CONSULTS 

3  Get  NUMBER  OF  INPATIENTS 

4  Get  NUMBER  OF  LIVE  BIRTHS 

5  Get  NUMBER  OF  OUTPATIENT  VISITS 

6  Get  NUMBER  OF  INPATIENT  VISITS 

7  Calculate  DAILY  MCCUS  by: 

7 . 1  (NUMBER  OF  ADMISSIONS  x  ADMISSION  VALUE)  + 

7.2  (NUMBER  OF  PHONE  CONSULTS  x  PHONE  VALUE)  + 

7.3  [(NUMBER  OF  INPATIENTS  -  NUMBER  OF  ADMISSIONS)  x 
INPATIENT  VALUE]  + 

7 .4  (NUMBER  OF  LIVE  BIRTHS  x  BIRTH  VALUE)  + 

7.5  [(NUMBER  OF  INPATIENT  VISITS  +  NUMBER  OF  OUTPATIENT 
VISITS)  x  VISIT  VALUE] 

8  Put  DAILY  MCCUS  in  DAILY  MCCU  FILE 

If  end  of  month  then 

9  Get  DAILY  MCCUS 

10  Calculate  MONTHLY  MCCUS 

1 1  Put  MONTHLY  MCCUS  in  MONTHLY  MCCU  FILE 
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2.0  SET  UP  PRODUCTIVITY  DATABASES 
For  each  clinic  do  the  following: 

1  Get  MONTHLY  WORK  UNITS 

2  Get  AVERAGE  MONTHLY  HEALTH  CARE  PROVIDERS 

3  Calculate  MONTHLY  CLINIC  PRODUCTIVITY  by: 

3.1  MONTHLY  WORK  UNITS  /  AVERAGE  MONTHLY  HEALTH¬ 
CARE  PROVIDERS 

4  Put  MONTHLY  CLINIC  PRODUCTIVITY  in  CLINIC  PRODUCTIVITY 
FILE 


For  the  hospital  do  the  following: 

5  Calculate  MONTHLY  HOSPITAL  PRODUCTIVITY 

6  Put  MONTHLY  HOSPITAL  PRODUCTIVITY  in  HOSPITAL 
PRODUCTIVITY  FILE 


3.1  PLOT  AND  CALCULATE  DAILY  MCCU  VALUES 
If  choice  is  display  MCCU  earnings  to  date  then: 

1  Get  DAILY  MCCUS 

2  Calculate  MCCUS  earned  to  date 

3  Display  MCCUS  earned  to  date 

Else  choice  is  graph  most  recent  30  days  worth  of  DAILY  MCCUS 

4  Get  DAILY  MCCUS 

5  Graph  DAILY  MCCUS 


3.2  PLOT  AND  CALCULATE  MONTHLY  MCCU  VALUES 
If  choice  graph  current  years  monthly  MCCUs  then 

1  Get  MONTHLY  MCCUS 

2  Graph  MONTHLY  MCCUS 

Else  if  choice  graph  previous  years  monthly  MCCUs  then 

3  Get  MONTHLY  MCCUS 
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4  Graph  MONTHLY  MCCUS 


Else  if  choice  make  predictions  based  on  historical  data  then 

5  Get  number  of  months  to  be  predicted 

6  Get  number  of  months  to  base  forecast 

7  Get  MONTHLY  MCCUS 

8  Forecast  months 

9  Display  forecasted  months 

9.1  If  one  month  then 

9.2  Display 

9.3  Else  more  than  one  month  then 

9.4  Graph 

Else  choice  is  make  predictions  based  on  user  predicted  inputs 

10  Get  number  of  months  to  be  predicted 

1 1  Get  number  of  historical  months  to  base  forecast 

12  Get  MONTHLY  MCCUS 

13  Get  future  months  values 

14  Forecast  months 

15  Graph  forecasted  months 

3.3  PLOT  AND  CALCULATE  HOSPITAL  PRODUCTIVITY 
If  choice  graph  any  six-month  period  hospital  productivity  then 

1  Get  six-month  period 

2  Get  MONTHLY  HOSPITAL  PRODUCTIVITY 

3  Graph  six-month  period 

Else  if  choice  make  predictions  based  on  historical  data  then 

4  Get  number  months  to  be  predicted 

5  Get  number  of  historical  months  to  base  forecast 

6  Get  MONTHLY  HOSPITAL  PRODUCTIVITY 

7  Forecast  months 

8  Graph  forecasted  months 
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Else  choice  is  make  predictions  based  on  user-predicted  inputs 

9  Get  number  of  months  to  be  predicted 

10  Get  number  of  historical  months  to  base  forecast 

11  Get  MONTHLY  HOSPITAL  PRODUCTIVITY 

12  Get  future  months  values 

13  Forecast  months 

14  Graph  forecasted  months 

3.4  PLOT  AND  CALCULATE  CLINIC  PRODUCTIVITY 
If  choice  graph  any  clinic  six-month  period  productivity  then 

1  Get  clinic  name 

2  Get  six-month  period 

3  Get  MONTHLY  CLINIC  PRODUCTIVITY 

4  Graph  six-month  period 

Else  if  choice  make  predictions  based  on  historical  data  then 

5  Get  clinic  name 

6  Get  number  months  to  be  predicted 

7  Get  number  of  historical  months  to  base  forecast 

8  Get  MONTHLY  CLINIC  PRODUCTIVITY 

9  Forecast  months 

10  Graph  forecasted  months 

Else  choice  is  make  predictions  based  on  user-predicted  inputs 

11  Get  clinic  name 

12  Get  number  of  months  to  be  predicted 

13  Get  number  of  historical  months  to  base  forecast 

14  Get  MONTHLY  CLINIC  PRODUCTIVITY 

15  Get  future  months  values 

16  Forecast  months 

17  Graph  forecasted  months 
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3.5  PERFORM  MCCU  ANALYSIS 

1  Present  MCCU  menu  choice 

2  Get  MCCU  menu  choice 

3  Present  MCCU  ANALYSIS 

3.6  PERFORM  PRODUCTIVITY  ANALYSIS 

1  Present  productivity  menu  choice 

2  Get  productivity  menu  choice 

3  Present  PRODUCTIVITY  ANALYSIS 
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APPENDIX  G 


DECISION  SUPPORT  SYSTEM  DATA  DICTIONARY 
DESCRIPTION 

This  appendix  contains  definitions  of  data  elements  found  in  the  data  flow  diagram 
and  referenced  in  the  mini-specification.  The  term  or  meaning  of  each  data  element  may  be 
found  here. 

ADMISSION  VALUE  =  10.0  *the  value  earned  for  admitting  a  patient  into  the 
hospital* 

AVERAGE  HEALTH-CARE  PROVIDERS  =  *the  average  number  of  health-care 
providers  present  in  a  clinic  for  the  month* 

AVERAGE  MONTHLY  HEALTH-CARE  PROVIDERS  =  CLINIC  NAME  + 
AVERAGE  HEALTH-CARE  PROVIDERS 


BIRTH  VALUE  =  10.0  *the  value  earned  for  a  live  birth  in  the  hospital* 

CLINIC  PRODUCTIVITY  FILE  =  {CLINIC  NAME  +  MONTH  +  YEAR  + 
PRODUCTIVITY}  *ftie  contains  all  clinical  monthly  productivity  values  for  the 
past  24-month  period* 

DAILY  MCCUS  =  DATE  +  MCCUS 

DAILY  MCCU  FILE  =  {DATE  +  MCCUS}  *file  contains  the  current  fiscal  year’s 
daily  MCCU  earnings  and  has  at  least  30  days  of  data  and  no  more  than  365 
days* 

DATE  =  YEAR  +  MONTH  +  DAY 
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HOSPITAL  PRODUCTIVITY  FILE  =  {MONTH  +  YEAR  +  PRODUCTIVITY}  *file 
contains  the  hospital’s  past  24  months’  worth  of  productivity* 

INPATIENT  VALUE  =  1.0  *the  value  earned  for  each  inpatient  in  the  hospital  each 
day* 

MCCUS  =  *a  value  that  equates  to  the  amount  of  health  services  rendered  by  the 
hospital  over  a  specified  period  of  time* 

MCCU  ANALYSIS  =  *any  type  of  data  in  any  format  provided  about  either  monthly  or 
daily  MCCUs  earned  in  the  past  or  projected  in  the  future* 

MONTHLY  CLINIC  PRODUCTIVITY  =  CLINIC  NAME  +  MONTH  +  YEAR  + 
PRODUCTIVITY 

MONTHLY  HOSPITAL  PRODUCTIVITY  =  MONTH  +  YEAR  + 
{PRODUCTIVITY}  *file  contains  the  past  24  months  of  hospital  productivity* 

MONTHLY  MCCUS  =  MONTH  +  YEAR  +  MCCUS 

MONTHLY  MCCU  FILE  =  {MONTH  +  MCCUS}  *file  contains  the  previous  year’s 
12  months’  worth  of  MCCU  data  and  the  current  month’s  MCCU  data  so  far* 

MONTHLY  WORK  UNITS  =  CLINIC  NAME  +  MONTH  +  WORK  UNITS  *the 
number  of  work  units  earned  by  each  clinic  on  a  monthly  basis* 

NUMBER  OF  ADMISSIONS  =  *admissions  the  past  24-hour  period* 

NUMBER  OF  INPATIENTS  =  *census  of  the  total  number  of  inpatients  past  24-hour 
period,  census  taken  at  a  specific  time  each  24-hour  period* 

NUMBER  OF  INPAT  IENT  VISITS  =  *total  number  of  inpatients  that  visited  clinics  in 
the  past  24-hour  period* 
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NUMBER  OF  LIVE  BIRTHS  =  *total  number  of  live  births  occurring  in  the  past  24- 
hour  period* 

NUMBER  OF  OUTPATIENT  VISITS  =  *total  number  of  outpatients  that  visited 
clinics  in  the  past  24-hour  period* 

NUMBER  OF  PHONE  CONSULTS  =  *total  number  of  patients  that  were  treated  over 
the  phone  by  health-care  providers  in  the  past  24-hour  period* 

PHONE  VALUE  =  0.3  *the  value  earned  for  a  phone  consult  to  a  patient* 

PRODUCTIVITY  =  *for  each  clinic  based  on  work  units  earned  each  month  divided  by 
average  monthly  health-care  providers  assigned* 

PRODUCTIVITY  ANALYSIS  =  *any  type  of  data  in  any  format  provided  about  either 
hospital  monthly  productivity  or  clinic  monthly  productivity* 

VISIT  VALUE  =1.0  *the  value  earned  for  a  visit  to  a  clinic  by  an  inpatient  or 
outpatient* 

WORK  UNITS  =  *a  value  that  equates  to  the  services  rendered  by  a  clinic  to  inpatients 
and  outpatients  over  a  one-month  period* 


127 


APPENDIX  H 


DECISION  SUPPORT  SYSTEM  STRUCTURE  CHART 
DESCRIPTION 

This  appendix  contains  the  transformed  data  flow  diagram  in  structure  chart  form. 
Data  elements  are  shown  passing  between  individual  modules.  Level  0,  the  context 
diagram,  shows  the  entire  structure  chart  on  one  page.  It  is  important  to  show  the 
morphology  of  the  system  because  poorly  structured  systems  can  be  identified  by  the 
downward  flow  of  modules  alone  [Page-Jones  80]. 


Context  Diagram 

(level  0) 


Page  5 


\ 
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APPENDIX  I 


DECISION  SUPPORT  SYSTEM  MODULE  SPECIFICATIONS 


DESCRIPTION 

This  appendix  contains  the  specification  of  the  major  modules  in  the  structure  chart 
written  in  pseudocode.  This  specification  in  pseudocode  follows  the  technique  of  Page- 
Jones  [Page- Jones  80].  The  module  specification  gives  a  more  precise  description  of  the 
graphical  presentation  found  in  the  structure  chart  This  textual  description  gives  guidance 
to  the  programmer  in  order  to  derive  source  code  from  system  documentation  [Page-Jones 
80]. 

MODULE  PUT  MAIN  MENU 

/♦Finds  what  user  wishes  to  look  at,  MCCUs  or  productivity  analysis*/ 

/♦Checks  choice  for  validity*/ 


Put  menu  choices 
Get  valid  choice 

If  not  quit  then 

If  request  for  MCCUs  then  call  module  to  display  MCCU  menu 
Else  if  request  for  productivity  then  call  module  to  display 
productivity  menu 


End  module 


MODULE  PUT  MCCU  MENU 

/♦Finds  what  user  wishes  to  look  at,  thirty-day  MCCU  trends  or  monthly 
MCCUs*/ 

/♦Checks  choice  for  validity*/ 

Put  menu  choices 
Get  valid  choice 
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If  not  quit  then 

If  request  for  thirty-day  MCCU  trends  then  call  module  to 
display  thirty-day  MCCU  menu 

Else  if  request  for  monthly  MCCU  data  then  call  module  to 
display  monthly  MCCU  menu 

End  module 

MODULE  PUT  THIRTY-DAY  TREND  MENU 

/♦Finds  what  user  wishes  to  look  at,  the  most  recent  thirty-day  MCCU  trend  or 
MCCU  earnings  to  date*/ 

/♦Validates  choice*/ 

Put  menu  choice 
Get  valid  choice 

If  not  quit  then 

If  request  for  most  recent  thirty-day  trends  then  call  module  to 
present  thirty -day  graph  (see  Figure  1-1) 

Else  if  request  for  MCCU  earnings  to  date  then  call  module  to 
put  MCCU  earnings  to  date 

End  module 


MODULE  PUT  THIRTY-DAY  MCCU  TREND  GRAPH 

/♦Gets  the  most  recent  thirty  days  worth  of  daily  MCCU  earnings  and  graphs  it*/ 
/♦Daily  MCCUs  on  the  vertical  axis*/ 

/♦Past  thirty  days  on  the  horizontal  axis*/ 

Call  module  to  get  most  recent  thirty  days  worth  of  data 
Graph  data  (see  Figure  1-1) 

End  module 
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MODULE  PUT  MCCU  EARNINGS  TO  DATE 

/♦Gets  the  total  MCCU  earnings  for  the  current  fiscal  year*/ 
/♦Totals  MCCU  earnings  and  puts  MCCU  earnings  to  date*/ 


Call  module  to  get  current  year’s  daily  MCCUs 
Total  daily  MCCU  earnings  to  date 
Put  MCCU  earnings  to  date 
End  module 


MODULE  PUT  MONTHLY  MCCU  MENU  I 

/♦Finds  what  the  user  wishes  to  look  at,  historical  or  projected  data*/ 

/♦Checks  choice  for  validity*/ 


Put  menu  choice 
Get  valid  choice 

If  not  quit  then 

If  request  for  historic  data,  then  call  module  to  display  graph  of 
historic  data 

Else  if  request  for  projected  data,  then  call  module  to  display 
graph  of  projected  data 

End  module 
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MODULE  PUT  MONTHLY  MCCU  HISTORIC  DATA 

/♦Depending  on  user  request,  graph  monthly  MCCUs  current  year’s  data  or  graph 
previous  year’s  monthly  MCCU  data*/ 

/♦Validates  choice*/ 


Put  menu  choice 
Get  valid  choice 
If  not  quit  then 

If  request  for  current  year’s  monthly  MCCUs  then 

Call  module  to  get  current  year’s  monthly  MCCU  data 


! 
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Call  module  to  graph  data  (see  Figure  1-2) 

Else  if  request  for  previous  year  monthly  MCCUs  then 
Call  module  to  get  past  12  months  of  data 
Call  module  to  graph  data  (see  Figure  1-2) 

End  module 

MODULE  PUT  MONTHLY  MCCU  PROJECTED  DATA 

/♦Depending  on  the  users  choice,  forecast  monthly  MCCU  earnings  based  on 
historic  data  or  user  input  predictions*/ 

/♦Validates  choice*/ 

Put  menu  choice 
Get  valid  choice 
If  not  quit  then 

If  request  for  projections  based  on  historic  data  then 
Get  number  of  months  to  be  projected  from  user 
Get  number  of  months  of  historic  data  to  base  projection 
on  from  user 

Call  module  to  get  historic  data 
Call  module  to  calculate  projections 
Call  module  to  graph  data  (see  Figure  1-2) 

Else  if  request  for  projections  based  on  user  input  then 
Get  number  of  months  to  be  projected  from  user 
Get  number  of  future  months  to  be  input  by  user 
Get  user  input  of  future  months 
Call  module  to  get  historic  data 
Call  module  to  calculate  projections 
Call  module  to  graph  data  (see  Figure  1-2) 

End  module 
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MODULE  PUT  PRODUCTIVITY  MENU 

/♦Gives  user  a  choice  between  clinic  or  hospital  productivity*/ 

/♦validate  choice*/ 

Put  menu  choice 
Get  valid  choice 
If  not  quit  then 

If  request  for  clinical  productivity  then  call  module  to  display 
clinical  productivity  menu  choice 
Else  if  request  for  hospital  productivity  then  call  module  to 
display  hospital  productivity  menu  choice 

End  module 

MODULE  PUT  CLINICAL  PRODUCTIVITY 
/♦Gets  choice  of  historic  data  or  projected  data*/ 

/♦Validates  choice*/ 

Put  menu  choice 
Get  valid  choice 

If  not  quit  then 

If  request  for  historic  clinic  productivity  then 
Get  name  of  clinic  from  user 
Get  months  to  be  graphed  from  user 
V alidate  months  requested 
Call  module  to  get  data 
Call  module  to  graph  data  (see  Figure  1-3) 

Else  if  request  for  projected  clinic  productivity  then 

Call  module  to  display  clinic  projected  productivity  trends 

End  module 
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MODULE  PUT  CLINIC  PROJECTED  PRODUCTIVITY  TRENDS 

/♦Gets  user’s  choice  to  forecast  monthly  clinic  productivity  based  on  historic  data 
or  user  input  data*/ 

/♦Validates  choice*/ 

Put  menu  choice 
Get  valid  choice 
If  not  quit  then 

If  request  for  projections  based  on  historic  data  then 
Get  clinic  name  from  user 
Get  number  of  months  to  be  projected  from  user 
Get  number  of  months  of  historic  data  to  base  projection 
on  from  user 

Call  module  to  get  historic  data 
Call  module  to  calculate  projections 
Call  module  to  graph  data  (see  Figure  1-3) 

Else  if  request  for  projections  based  on  user  input  then 
Get  clinic  name  from  user 
Get  number  of  months  to  be  projected  from  user 
Get  number  of  future  months  to  be  input  by  user 
Get  user  input  of  future  months 
Call  module  to  get  historic  data 
Call  module  to  calculate  projections 
Call  module  to  graph  data  (see  Figure  1-3) 

End  module 


MODULE  PUT  HOSPITAL  PRODUCTIVITY  MENU 

/♦Gets  choice  of  historic  data  or  projected  data*/ 
/♦Validates  choice*/ 

Put  menu  choice 
Get  valid  choice 
If  not  quit  then 
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If  request  for  historic  hospital  productivity  then 

Get  months  to  be  graphed  from  user  . 

Validate  months  requested  ^ 

Call  module  to  get  data 
Call  module  to  graph  data  (see  Figure  1-3) 

Else  if  request  for  projected  hospital  productivity  then 

Call  module  to  display  projected  hospital  productivity  ^ 

End  module 


MODULE  PUT  PROJECTED  HOSPITAL  PRODUCTIVITY 

/♦Gets  user’s  choice  to  forecast  monthly  hospital  productivity  based  on  historic 
data  or  user  input  data*/ 

/♦Validates  choice*/ 

Put  menu  choice 
Get  valid  choice 

If  not  quit  then 

If  request  for  projections  based  on  historic  data  then 
Get  number  of  months  to  be  projected  from  user 
Get  number  of  months  of  historic  data  to  base  projection 
on  from  user 

Call  module  to  get  historic  data 
Call  module  to  calculate  projections 
Call  module  to  graph  data  (see  Figure  1-3) 

Else  if  request  for  projections  based  on  user  input  then 
Get  number  of  months  to  be  projected  from  user 
Get  number  of  future  months  to  be  input  by  user 
Get  user  input  of  future  months 
Call  module  to  get  historic  data 
Call  module  to  calculate  projections 
Call  module  to  graph  data  (see  Figure  1-3) 


End  module 
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Figure  1-1.  Sample  30-Day  MCCU  Graph 
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Figure  1-2.  Sample  MCCU  Monthly  Earnings  Graph 
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Figure  1-3.  Sample  Clinical  Productivity  Graph 
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